I just identified some areas or building block every application needs within its foundation. All of these areas are covered already by SAP Java components or other APIs. My proposal is to be aware of them and keep them in mind in the planning process so your application stays maintainable over time. Once identified, you can put them in your common toolbox and reuse them for most of the other upcoming applications without much effort of thought. This weblog shall give you a short overview over the essential blocks of an application and what choices are available. The most obvious: every application must have a UI, which you may not be free to choose. You either program a command line tool, a Web application or a desktop application. My personal dream would be that all the frontend technologies could be programmed in a similar way. I love Swing not because of its performance and great looks, but because of its well-thought-out API. Why not program a SWT UI (Eclipse) in the same way, or even a Web interface? It's discouraging to learn a new API for every new UI technology. SWT is a lot faster and nicer looking than Swing but has a pretty different API. Web programming is also a lot different from Desktop applications. SAP proposes Web Dynpro as the tool and API for building UIs for business applications that are webbased. The meta model is very intriguing and has an abstraction layer that separates client side rendering from the programming model. That means you can program almost the same way for handheld devices as you do for browsers and that browser independent. From my point of view, it would be interesting to see SAP generate Swing UIs out of the Web Dynpro Meta Model also.
Another very basic but confusing topic in the Java world is persistence. What should I choose? JDO, EJB CMP,BMP, Castor, Torque, OJB, JDBC, SQLJ ... The choice and variety is quite annoying. Every solution has advantages and disadvantages but not one seems to be completely satisfactory. SAP offers JDO, EJB and SQLJ right out of the box with some tool support. I think the standards JDO and EJB CMP have evolved already but still are missing some features that could be covered by vendor extensions. The support for automatic generated keys is one example that is missing. Also does the query language for both still need some improvements. With these many options I sometimes ask myself: Was SQL actually so hard to begin with? What happened to stored procedures? Interestingly enough, I think .NET developers do not spend as much time finding the right persistence framework. They use ADO.NET and that's it. Is that good or bad? What's your opinion? Which one do you like the most? Personally, I like my own persistence framework the best ...
Now we're coming to the region where it's more concrete: Logging. Better to use a good logging API right from the start. You will need to remove all System.out anyway later on. I found good log statements can be faster to find problems than debugging. Here the clear winner in the open source world is Log4j. The SAP Logging API is even mightier and should be the first choice for all SAP Java developers. It adds the great advantage that it is very tightly integrated into the server and prints a lot of information that enables you to trace requests even by user. Of course writing good log statements is another issue. The log statements should be meaningfull to others. This might be worth discussing in another weblog.
Security and User Management. Standards like JAAS have evolved and proven very helpful in making user stores pluggable. Still, normal J2EE security falls short of real business requirements. Here, the SAP UME comes into play and I think it's very powerful. This is definitely a User API that can achieve most of the goals. Let's propose it as JSR (if there isn't one already, never sure ...). As I am also an Open Source fan, I'd like to see something like that in the Open Source world.
A good and consistent Exception handling is always worth a thought beforehand. The SAP exception API is probably the choice but unfortunately I haven't had time to look at it very extensively. The concept for all exception frameworks is valid for all. First, you need at least two exception classes as base classes for all your custom exceptions. If all other business exceptions extend these exceptions you can just catch the base exception. A very good example is the java.io API. Everything inherits from IOException like the FileNotFoundException. You need two exception base classes because one must extend RuntimeException which does not need to be declared in the throws clause. Also, these exceptions must be able to wrap the original exception, so when rethrowing an exception, the original stacktrace is preserved. Consider also that every exception can show the error message in an internationalized way. Of course, there are some philosophical choices. When should I use runtime and when checked exceptions? Should I rethrow an exception or catch it? Consider a retryable pattern. If the client gets an exception, could he maybe retry the same operation? For example: a resource may be blocked at the time, but 10 milliseconds later it's not.
Configuration Management is not often discussed but has to be considered from the beginning. This means you have the ability to configure your application, without recompiling or redeploying it. The simplest way is to use Java resource bundles or the java.util.Properties class. I use a framework where you have a ConfigurationManager Interface (not to be confused with SAP Configuration Manager!!!). The ConfigurationManager Implementation could then read or store the settings in a flat file, XML, database or serialized object. There could be support for hierarchical entries under a key or multiple entries under a key. A great feature would be to personalize certain settings per user. It's useful to introduce a central configuration management for every application. Web Dynpro has a configuration model that follows the same idea.
Internationalization. I've had so many projects where we thought: "No, we'll never need this" . But later on, it's always been required. I hate the topic because it's boring to extract all your hardcoded messages out of the application and make them keys instead, but there are tools to help. You should consider internationalization right from the start. Sooner or later it will come. Thanks to SAP, at least you considered it in your IDE. That's it. I hope I left you with some food for thought. I strongly believe this is the truth. I just haven't found the total truth about persistence yet. So be it.
