J2EE Development Standards
Total Page：16
File Type：pdf, Size：1020Kb
Indiana University J2EE Development Standards University Information Systems September 2004 Version 1.4 Table of Contents Introduction............................................................................................................... 3 Methodology..............................................................................................................6 Architecture...............................................................................................................12 Coding Conventions..................................................................................................18 Standard Libraries ....................................................................................................20 Tools ..........................................................................................................................21 Development Platform ..............................................................................................22 Shared Services .........................................................................................................23 Deployment................................................................................................................24 References and Links................................................................................................26 Appendices.................................................................................................................28 J2EE Development Standards v1.4 - 2 - J2EE Development Standards: Introduction Why have we developed this J2EE Development Standards document? Most developers are aware of the benefits of development standards as they relate to long term maintenance costs. 80% of the lifetime cost of a piece of software goes to maintenance. Often times, the original author of the code does not perform the maintenance. So, it stands to reason that, over the long haul, applying standard development practices across an organization will result in substantial maintenance savings. In addition, good standards promote better quality applications, code reuse, and may enhance portability. In addition to this fairly common definition of why we have standards, this document serves another purpose. It is hoped that this document will provide simple and concise instructions that may actually make it easier to develop applications in UIS. In order for standards and guidelines to achieve these stated goals, developers must adhere to them. To encourage them, the standards and guidelines must be easy to follow and relatively flexible. Finally, project plans must accommodate compliance. Avoiding standards due to project deadlines is not a valid excuse. Complying with standards should be built into work plans. UIS management must support compliance. The “quick path” solution today will cost us dearly in maintenance over the life of our applications. A standards-based approach gives us more time over the long run to work on new services. Whether you are a brand new developer in UIS or a seasoned programmer, we hope that you find this document easy to follow and helpful. If you do not find it helpful or if you have suggestions for improvements, please contact the Systems Integration Team. Our goal is to help UIS development teams do their jobs more effectively and efficiently. What is a “Standard”? For the purposes of this document, a “standard” is a development practice that is deemed most important to ensure that we do not compromise on our collective and fundamental development principles. Therefore, “standards” outlined in this document should be strictly adhered to by all J2EE developers in UIS. With each exception, we lose on the maintenance side. So, it is expected that all UIS J2EE developers will adhere to these standards. If a particular standard is preventing us from making progress on our deliverables, what are our options? J2EE Development Standards v1.4 - 3 - It is never the intent for the standards to prevent work from getting done. The intent is for the standards to provide more help than hindrance to the development process. If a situation should arise where an application team feels it must deviate from a standard, the first step is to communicate with the Systems Integration Team. It could be that via email discussion or a short meeting, we can collectively arrive at a recommended approach. In some cases, we may find a way to solve the problem and still adhere to standards. In other situations, we may need to make an exemption to a particular standard. Either way, if the petitioning application team and SIT are in agreement on the recommended approach, the problem is resolved. (Note: Depending on the frequency of a given issue, the application area may move to make a permanent change to the standards document. This process is described in the next section). If for some reason the application team and SIT cannot arrive at a means of complying with a standard, the Director or the Director’s designee for the petitioning application area will be provided information describing the alternatives and the pros and cons of each. The Director or their designee will then resolve the issue in a timely manner, to allow development to proceed. The application team should then bring up the issue at the next meeting of the J2EE Standards Committee to accommodate future instances. (See discussion of Committee below.) Teams should be aware that deviations from standards may adversely affect the level of support other UIS teams, including SIT, will be able to provide a given application. How can a standard be changed? What if a standard is not “helpful”? In addition to the goals for minimizing long term maintenance costs of UIS applications, this document is also intended to help UIS developers do their job. If for some reason a particular standard is problematic or unhelpful to this process, there must be a way change it. UIS is still very new to J2EE development and we continue to learn new things every day. Therefore, this standards document must be a living, evolving document. It is not recommended that it be printed off and put on a shelf for years. Rather, the latest and greatest version of the document should be checked out frequently to be sure that even the most recent changes are reflected. SIT will publish “Release Notes” with each new version of the document making it easy to identify the latest changes. If a particular standard is not helpful or is frequently causing problems, a proposal to change the standard can be brought forth by any UIS application team, infrastructure team, or SIT. These changes to standards can be discussed in one of two venues. First, if it is an urgent topic, it can be addressed at the next meeting of the developers’ “Java Hour”. In addition, a J2EE Standards meeting will be scheduled once a quarter to discuss proposed changes to this document. Either venue is an appropriate meeting to discuss changes to the standard. J2EE Development Standards v1.4 - 4 - A “J2EE Standards Committee” will be established to determine and regulate J2EE standards for UIS. This committee will be made up of people appointed by their managers representing application development teams across all of UIS. Every UIS development team will be represented. Regular attendance by J2EE Standards Committee members will be required. The time commitment is relatively small. Eighty percent (80%) of the members of the Committee must be present to conduct business. Any proposed change to the written standards must be approved by eighty percent (80%) of the members present. The meetings will be scheduled on a quarterly basis. Meetings will take place only when there are agenda topics or standards modifications up for discussion. Emergency meetings may be scheduled when decisions need to be made quickly. Who “owns” these standards? Every J2EE developer in UIS owns these standards. It is the developers that must maintain UIS code over the long term. It is the developer who is accountable for their code and productivity. Therefore, the developers are the rightful owners of these standards. SIT does not own the standards nor will SIT implement any sort of formal enforcement process. UIS members may point out potential deviations from standards and make a point to communicate their concerns, but that is as far as it will go. It is up to each developer in UIS to actively participate in this process, encourage and train new developers to adhere to the standard, and to make the standards helpful to meeting the overall goals and objectives of UIS. J2EE Development Standards v1.4 - 5 - J2EE Development Standards: Methodology A methodology for software development should establish procedures and techniques that developers can rely on to promote quality software and services. Adopting a methodology means following a prescription of methods that the developer community has judged to be useful, coherent, and worthwhile. What is the value of a Methodology? When we follow an established software methodology, we gain from the experiences of others in developing software that satisfies user requirements. We can take advantage of proven best practices, and avoid the pitfalls that have crippled or scuttled other projects. An effective methodology must consist of methods that work, and work consistently across a wide range of requirements. Most application projects involve a number of analysts and developers. Coordinating their efforts is crucial to the success of a project. A methodology focuses and integrates the efforts