After having a good day start I went over to the architecture of AJAX applications session where the main focus was on performance issues with web application and how to solve them with a good architecture and design. From my understanding it mainly comes down to move more of the view and controling logic to the browser and separate presentation from data. For the view and data typical optimizations for cache and content reduction should be applied. Which ranges from stripping spaces from files where possible to using lightweight protocols like JSONP for data access and browser-server communication.

The third session talked about Oracle’s Toplink (which is also called EclipseLink) and the Coherence integration with regards to performance. Most interesting is the possibility to execute queries agains the shared cache and not touching the database at all. Which reduces a lot of load from database and network for high performance applications. It might also work quite well for highly transactional applications.

The second keynote disappointed me because most of the time a video from youtube was shown. I expected more examples and best practices. Also the session afterwards only showed a small amount I expected from the topic.

Beside this the last session was interesting again. Talking about common class loader issues in web applications it showed some interesting failures which occur when not understanding class loading and Hot Code-Replacement in Eclipse or shared libraries in application servers. The last presentation about the memory leak when using ClassLoaders and constants is a nice eye catcher. I would like to have seen some problems in an OSGI platform.

Beside all the sessions and keynotes I also meat some old and new collegues and enjoyed the great day!

What’s so interesting about Scrum is the management by sticking to some simple rules and focus on business value. The main point I got out of the workshop is the importance of priorization and separation of business function and technical realisation. With this approach the team is in fully response to find the best solution for the functionality in a given amount of time. This way no one builds nice looking architectures in the ivory tower. The team develops the architecture as part of the first story. Because of priorization this architecture is based on the story which provides the biggest business benefit.

Also the estimation based on  a freely choosen reference story is a nice way. Doing it this way there is no effort estimation but only functionality estimation.  So keep out the hours! The team estimates the functionality and afterwards decide how much it can handle in one Sprint (which might last 2 weeks or 1 month). After this first initial Sprint is finished there is a measurement how much functionality a team can handle. While doing more and more Sprints the average story points a team can handle in a a Sprint is measured and not estimated. The word measurement sounds much better than estimation because it provides a picture that it is based on a real value and no guess. Which it somehow also is. So from a management point it look s much more feasable.

The role of  a Scrum Master as a person who ensures that the small amount of principles are followed and everyone fulfills his duties makes it a challenging opportunity. I hope I can work in this role in some future.

Also one of the most interesting sentence was the questions Mr. Roock asked his customers when he gets called for a Scrum consulting. He askes customers whether they want Scrum for the complete company or only a single project. Based on his objections bringing Scrum to a project has only a single effect to the project but bringing it to the company provides a much higher productivity afterwards. But this also means that some iterations in the introduced project will fail.

http://it-republik.de/jaxenter/news/JAX-TV-Swing-Application-Framework-054008.html

A common way of shutdown implementation is to add an implementation of WindowListener to the application frame and react on the events. The listener already has a callback windowClosing(WindowEvent) which is called before the window closes. Here the application might ask the user if he really wants to exit or just clicked the wrong button . In most cases if the user commits a common implementation is to invoke System.exit(0) because this terminates the JVM but the JFrame class provides a more convinient approach. Simply set the default closing operation to JFrame.EXIT_ON_CLOSE will do the same job. If the application requires a callback that the application frame is really closed simply set the closing operation to JFrame.DISPOSE_ON_CLOSE and implement the listeners windowClosed(WindowEvent) method. You even don’t need to invoke System.exit(int) because the EDT exits when no window is active. Which means if the application frame is the only window it also exits the application.

This image shows the event invocations when a window is closed. First the user closes the window by pressing the red icon in the top right corner. This causes the EDT to dispatch a window event to the application frame. The event has the type WindowEvent.WINDOW_CLOSING. The application has registered a WindowListener that invokes shutdown in the EDT. In the shutdown method the application asks the user if he really wants to exit. If he aborts the application sets the default close operation to JFrame.DO_NOTHING_ON_CLOSE which continues the application and keeps the frame open. If the user commits the application sets the default close operation to DISPOSE_ON_CLOSE which causes the application frame to be disposed. This again causes the EDT to dispatch a new WindowEvent with the type WindowEvent.CLOSED. Now the application can do some magic in the EDT after the window is closed. If no window exists the EDT exits and the JVM terminates. If the application sets the default close operation to JFrame.EXIT_ON_CLOSE the application will terminate immediately after the windowClosing method is executed (just look at the code of JFrame’s processWindowEvent method).

A really simple approach is shown in the following picture.

The user starts the application either using Web Start, clicking on the JAR or command line. In the applications main-method is one line Launcher.launch(Application.class, args) where the application class and command-line arguments are passed to the launcher. This one creates a new application instance and invokes the startup method in the EDT using SwingUtilities.

Because no window is shown any configured splash screen will be shown until the frame (or window) which is created in startup method is shown to the user. The behavior of startup is application specific but often it can be divided into an initialization part of the platform. Typical services like executor, communication layers, logging, modularization are initialized. After this is completed the application frame is created and shown to the user.

But nothing comes for free, a problem occured as I added class-path entries to the manifest.  The splash screen was not shown! So I played around with a dozen of combinations in the manifest file. The outcome is that if the Splashscreen-Image entry is after the Class-Path entry no splash screen will be shown! So always keep you entry for the splash screen at the top of the manifest file.

So the first I had to do was browsing the documentation at Adobe Open Source and getting a feeling of Flex. This means mainly downloading the SDK, looking at the examples and fiddling around with them. The concept with declaring the user interface in XML is nice and makes it really easy building simple forms and screens. With the mechanism of having an id-map in the application from where the application code, UI and everything gets and displays the entered/computed text works well. Also with ActionScript which is like JavaScript but with just a little bit more type information makes it also easier for a Java developer to dig into it. One of the biggest points is the extensive API documentation. The structure with having an example available for each UI component and function is quite charming. I hope to see this kind of documentation also in some other projects.

As an example I’d written a small application to calculate the real inflation adjusted return for a one-year cash-investment in a CD.

Again, first we need to set up the Maven project with all required dependencies and build settings. The goal is to generate the client implementation with CXF and write a small test case. So we set up the typical maven project and add the cxf-codegen-plugin to the build settings. This Maven plugin has the goal wsdl2java which must be executed with the configuration pointing to the location of the WSDL of the deployed service. Often it is something like http://localhost:8080/axis2/services/Foo?wsdl. Also the project needs the Spring Framework and Apache CXF as dependency.

The second step is the test case. This one should be written using spring-tests which provides a basis for test cases requiring a Spring IoC container. The configuration file (also known as application-context file) requires the two CXF imports and the service client definition using jaxws:client tag. If the service provider requires authentication one can add the required processors to the output queue using jaxws:outInterceptors and e.g. the WSS4JOutInterceptor as a bean.