Previous    Next

Summary

In this chapter we've discussed the importance and benefits of a strong generic infrastructure backing app implementation. While aJ2EE app server provides powerful standard infrastructure forJ2EE apps, we need to use additional infrastructure components to make the J2EE APIs easier to use, ensure that app code focuses on addressing business problems, and solve problems that the J2EE specifications do not. To illustrate these points, and to provide a potential basis for your own apps, we've examined some of the key infrastructure packages used by the sample app, and the problems they exist to solve. We've considered the importance of infrastructure that enables central configuration management. We've seen how making app components JavaBeans can allow them to be configured by a generic app framework, removing the need for app code to implement configuration management such as property file lookups. In combination with interface-based design — in which code is always written to interfaces, rather than classes — the use of JavaBeans is an incredibly powerful means of assembling and parameterizing apps without modifyingJava code. Once configuration management is centralized, it is possible to read configuration from any source — such as XML documents, properties files, or JNDI - twithout any need to change app code. Configuration viaJavaBean properties ensures consistency across apps and between architectural tiers. For example, EJBs can use the same approach to configuration management as ordinary Java classes. We've looked at several layers of infrastructure that enable us to achieve central configuration management:

• A package that abstracts the use of reflection to manipulate JavaBeans. This is valuable basic infrastructure that can be used not only in configuration management, but also for other tasks such as initializingJavaBean objects from HTTP requests (as discussed in the next chapter), simplifying request processing in web apps. This functionality is so useful that several open source projects, such as Apache Commons, provide their own implementations; however, I am yet to see a really good one, and the com.interface21.beans package described in this chapter is the most sophisticated I know of.

• A "bean factory" that uses this lower-level functionality to maintain a registry of app objects. When app objects are defined as JavaBeans, they need not depend on this infrastructure; infrastructure can work behind the scenes to set bean properties to configure objects, including setting relationships between objects, based on definitions held outside Java code.

  With the combination of built-in support for primitive properties, the ability to set relationships between managed objects, and the availability of the standard JavaBeans PropertyEditor functionality to represent object types as strings, concise bean factory syntax can define complex app configurations. We looked at standard bean factory implementations based on XML documents, properties files, and environment variables defined in EJB JAR deployment descriptors.

• An "app context" that builds on the bean factory concept to implement the Observer design pattern, provides a standard way to look up messages to meet internationalization requirements, and allows app components to communicate as necessary at run time.

The standard J2EE infrastructure makes some simple things difficult, which has caused widespread frustration with J2EE in practice. This can be addressed by a simplifying infrastructure that makes J2EE APIs and services easier to work with. We've seen how infrastructure can be used to simplify working with complex J2EE APIs, including:

• Support classes that make it easier to implement EJBs and reduce the likelihood of common errors.

• Infrastructure classes that help to implement the Service Locator and Business Delegate J2EE patterns, decoupling code that uses EJBs from dependence on JNDI and EJB APIs. We saw that the Service Locator pattern is usually simplest and most appropriate for accessing EJBs through local interfaces, while the Business Delegate is the better choice to access EJBs through remote interfaces. In this case the Business Delegate can be used to conceal the details of remote access from client code.
• Classes that make it easier to send and consume JMS messages, concealing the necessary JNDI lookup, simplifying error handling and the need to work with multiple JNDI API objects.

Whether or not you choose to use the specific infrastructure described in this chapter, all these issues should be addressed outside app code, which should concentrate on the problem domain and implementing business logic.

Finally, we looked at some of the core implementation of the sample app, illustrating how it is simplified through use of appropriate infrastructure.

Previous    Next