Back

• Independence: The application framework must work smoothly across various platforms and environments. For example, the application framework must be generic enough to support (or, easily extendable to support) various application servers, operating environments (e.g., Solaris, Linux, HP/UX, AIX, Windows NT/2K/XP, etc.) and corresponding hardware platforms, software vendors for a certain purpose software (e.g., databases), and so on.
• Flexibility: The framework needs to be flexible in its usage. Various services of the framework must be accessible directly various application modules or components (such as, a simple Java class, EJB, Servlets, JMS listeners, and likes.)
• Scalability: Scalability must be kept in mind while designing an application framework. This will allow adding new components to the framework and new services to a framework component without requiring existing applications to modify their code.
• Documentation: Knowledge dissemination is the key in the success of an framework. A well defined API with precise and sufficient documentation will help enhance its usage. The framework code must be well documented according to JavaDoc guidelines. A well formatted description of the framework with generated JavaDoc must be made available in appropriate media (print, web, etc.)
• Simplicity: The application framework must be simple to use. Simplicity can be achieved by providing relatively shallow hierarchies in inheritance, consistent API across the framework components, and minimum number of object creations. The Java Collection package can be considered as an example of a simple framework.
• Common Ground: The application framework must make some assumptions to support the lowest common denominator with regards to its services. For example, if the framework provides JDBC related services, it must put the assumption to support a particular version of JDBC driver. Similarly, it must define the support for JDK version, EJB version, application server version, versions of other supported applications and packages..
• Less Is Better: An application server must provide a very basic functionality - which will be common to all supported environments and platform. The goal here is to help the development teams not spend time in basic common services, but, at the same time, not to ease them in their business specific development work.

• Retrieve Value: Retrieves the parameter value of a given variable. The service traverses through the XML document tree to locate the exact variable and to retrieve its value. The component throws a configuration exception if it can  not locate the supplied variable in the XML document tree.
• Retrieve Multiple Values: Retrieves parameter value list for a desired variable. This retrieval works the same way as in the previous retrieval service. However, in this case the service returns a collection of values for the supplied variable.
• Retrieve Typed Value: This service retrieves parameter value in a given data type. The component provides a set of convenient methods to retrieve the variable values in desired data types, such as double, int, String, boolean, etc. It accomplishes this by converting the variable value in desired data type. In doing so, the component makes sure that the incoming value is in the proper format to be converted into the desired data type. Otherwise, the service generates a configuration exception to indicate the problem.
• Retrieve XML Element:  For a given variable (key), this service locates the supplied variable and returns the corresponding Element. This service helps developers to get the entire element from the configuration of a component and perform desired manipulation of the retrieved Element.

• Independence: Logging Services component is independent of platforms and vendors.
• Configurability: Logging Services component is dynamically configurable. This allows clients to change one or more of the configurable items without shutting down and restarting the Logging Service component. For example, the output channel can be changed from the console to a file stream, dynamically. This will cause the Logging Services component to switch message logging/printing  from the console to the supplied file stream.
• Message Categorization: It provides message type and message severity level definitions for messages to be logged. These types and severity level definitions are configurable. For example, severity level definitions for a particular application can be FATAL, ERROR, WARNING, DEBUG, DEBUG_APP, DEBUG_METHOD, DEBUG_EXCEPTION, INFO, etc. Similarly, the message types can be defined as SYSTEM, APPLICATION, and so on.
• Output Channelization: The Logging Services component provides a mechanism to direct messages to a desired destination (we will call it a channel). This is achieved through configurable items with the help of Configuration Services component. However, the destination channel can also be changed dynamically while application is in operation. In other words, the Logging Services component provides a pluggable message logging channel. The component supports the following output channels:
  • ConsoleLogger – This channel uses PrintWriter which can be attached to an instance of java.io.PrintWriter, System.err, System.out. This channel will not be suitable for EJBs since EJB specification suggests not perform java.io operations.
  • MemoryLogger - write messages into systems memory.
  • StreamLogger - messages can be written into any kind of streams.
  • FileLogger - messages are written to a file. The file can rotate on a predefined time interval.
  • SocketLogger - a socket handles the message logging.
  • MDBLogger - This logger uses message driven Enterprise JavaBean as its message processor for logging purposes. It works on the principles of Java Message Services (JMS). A message driven bean (MDB) is automatically created by an EJB container, when a message arrives to the message queue or the message topic defined in the component configuration. This channel is very useful in distributed environments (especially using EJBs) where multiple machines can be involved in the application and a unified view of logging is desired.
  • DatabaseLogger – Ithe component writes messages to a database.
  • EmailLogger - messages can be sent directly to an email account using JavaMail protocols. This logger can be used to send pager as well. However, sending email is relatively an expensive operation. Hence, cautions must be taken in its use.

   

• Message Filtering: It provides a filtering mechanism to filter out messages up to a desired level of severity.

• Object Filtering: It provides a mechanism to have various components register themselves to this component. In such scenario, the filtering mechanism provides a facility to filter out all unregistered objects and their messages will not be logged.
• Persistence: Log messages are persistent. This helps trace any problem encountered during the execution of the application. However, the component has the facility to direct the logging messages to the standard output screen. This can be helpful during the development phase. This feature can be removed in the production release of the application.

  The message persistence is achieved by directing log messages and events to a database. The log database is to be different from other transactions. In other words, the log database must not be a part of a transaction. Otherwise, the log message will also be rolled back should an unexpected situation arise.

• Distribution: Logging Services provides a mechanism (through configuration) to allow itself to either be a local logging facility or a centralized logging facility. The local logging facility is helpful in simple application or for debugging purposes of a single component. On the other hand, a centralized logging facility is a must in a distributed environment. In a J2EE-based distributed environment, the application server can move J2EE components (e.g., EJBs, etc.) from one physical machine to another due to failover, load balancing, and other similar situations.
• Message Formatting: The log message format is configurable to achieve flexibility in the message formatting. A particular application will have a capability to define and configure what information goes into a log message and how these information will be formatted. This will help application to prepare a report on log message in a desired format. The Logging Services component handles both plain text (human readable) format as well as XML (detailed XML-structured) format.
• Problem Handling: If this component detects that the log database is down, it sends an alert message. Further calls to this components do not do anything. However, it will provide a mechanism to check its status.

• Bootstrap: The component is started with logging configuration data as its input. The component reads the configuration data and sets up various logging features after parsing the configuration data and retrieving all relevant information. This is achieved through the component instantiation. In real world, this component may represent a singleton class with static methods.
• Add Logger: This service allows to have more than one instance of the logging services component. This can be useful if developer wants to log all debugging messages at one place and all other application related messages at other.
• Set Logging Level: This method allows clients to set the severity level of the message to be logged. Any message of severity level lower than this will be ignored.
• Set Logger: Sets a particular given logger as the default logger. This remains effective until another call to this services is made. This allows the use of plain log methods that do not require to send in logger as one of the parameters.
• Set Log Formatter: This method sets the default message formatter to the given formatter (simpleformatter, or xmlformatter).
• Message Logging: The component provides a host of overriding methods to enhance its usability in message logging. Various versions of the log method serve different purposes in terms of information passing to the logger. Following are a few examples of the overriding log method:

  • log(message) - a simplest form for just sending the message.
  • log(logger, message) - a simple message to a particular logger.
  • log(level, message) - message with its severity
  • log(logger, level, message)
  • log(level, object, message) - message with its source information
  • log(logger, level, object, message)
  • log(throwable) - errors and exceptions
  • log(logger, throwable)
  • log(object, throwable) - errors and exceptions with source info.
  • log(logger, object, throwable)
• Convenience Services: In addition to the defined set of standard log methods above, the component provides a large set of convenience methods for logging messages of various types. Examples of such convenience methods are error(...), exception(...), warning(...), debug(...), info(...), and so on. This set of methods is intended for developers who want to be able to locate the source of a given logging message. Each of these methods will also have various forms for selecting default parameters as well as supplied parameters.

• Checked exceptions throwable by a method must be declared with a throws clause, in a comma-separated list of exception types. Only exceptions not caught within the method must be present in the list.
• Always declare the individual exception types in the throw clause, rather than declaring their super class.
• You must throw only a type of checked exception that has been declared in the throws clause.
• Handling checked exceptions provides three choices – catch the exception and handle it; catch the exception and map it into one of your exceptions by throwing an exception of type declared in your own throws clause; or declare the exception in your throws clause and let the exception pass through your method.
• The throws clause of an overriding method must be compatible with the throws clause of the inherited method – whether abstract or not.
• A superclass catch clause can not be put before a catch clause of one of its subclasses.
• Always catch specific exceptions. A catch clause that catches java.lang.Exception is a very poor implementation choice since it will catch any exception, not just the specific desired ones.
• A finally block should be used to clean up the internal state, to release non-object resources, for break, continue and return. A finally block must follow catch blocks, if any.
• Exceptions should not be used for simple, predictable, and expected situations.
• Do not catch javax.lang.RuntimeException or error in a bean method. This way the errors get propagated to the bean’s container.
• If your bean method can not recover from a checked exception, wrap the  original exception in javax.ejb.EJBException and throw this new exception..
• Report any other unexpected error condition using javax.ejb.EJBException.
• Do not list javax.ejb.EJBException in the throws clause of a bean method.

• Getting InitialContext: This service requires an URL an its input and creates a naming context of type javax.naming.InitialContext. This naming context consists of a set of name-to-object bindings. It contains methods for examining and updating these bindings.
• Getting Home Interface: This service looks up the given JNDI name and narrows the resulting object reference to the given type. This resulting object is the proper home interface of a particular EJB. The narrowing activity checks to ensure that an object of a remote or abstract interface type can be cast to a desired type. The service is useful in creating a new instance of the EJB.
• Lookup Object: This service is very similar to Getting Home Interface service with an exception that it can be used to perform JNDI lookup for any desired object in the JNDI lookup tree.
• Getting Message Sender: Performs the lookup in the JNDI context for a given connection factory (QueueConnectionFactory or TopicConnectionFactory) and for the Queue or Topic name. It uses the connection factory to create a connection (QueueConnection or TopicConnection), which in turn helps create a session (QueueSession or TopicSession) object. Finally, the service creates a message dispatcher (QueueSender or TopicSubscriber from the session and pass the sender to the its client. The message dispatcher is used to send messages.
   

• The persistence services must be vendor and platform neutral. It is assumed that the underlying database support JDBC drivers.
• It will provide generic services and not any vendor specific features.

• Make Connection: Based on the supplied parameters, this services makes a connection to the requested database and provides a java.sql.Connection object. This Connection object provides other services to the connected database. Various parameters needed to make a successful database connection include JDBC Driver's name, database user name, database user password, and a network address (URL) where the database server resides.
• Set Database Instance: Once the database connection is established, a particular database instance can be made active for further use, through this service.
• Retrieve Data: This service executes either the supplied SQL statement or the callable statement, and provides a Collection of ResultSet. SQL statement handles the simple queries while the CallableStatements will handle stored procedures.
• Format ResultSet: This service iterates through each column of the ResultSet and writes down the column values to the given stream. The client can use this stream to either display the results on the console or write to a file.

1. “Enterprise JavaBeans Specification, Version 2.0”, Sun Microsystems, Inc., April 2001.
2. Richard Monson-Haefel, “Enterprise JavaBeans, Second Edition”,  Orielly & Associates, Inc., MARCH 2000.
3. Ken Arnorld, James Gosling, David Holmes, “The Java Programming Language, Third Edition”, Addison-Wesley, June 2000.
4. Seth White, et. Al., “JDBC API Tutorial and Reference, Second Edition”, Addison-Wesley, December 1999.