Smart421′s Staff Weblog

This years Autumn JAX conference was actually two conferences in one. The OSGi DevCon shared two days with the main JAX event. Conference delegates were then free to attend sessions from either conference. This meant that developers with little experience of OSGI really benefited from gaining insight across sessions. This years event was very well attended, the huge conference room in the London Novotel was packed, with people standing. The sessions were only 50 mins each which meant they were kept concise and to the point, so no chance of getting bored. The smaller rooms were intimate and made asking questions much less intimidating. You could feel the enthusiasm of everyone during the breaks, people were chatting and networking rather than hiding away behind their laptops. Lets not forget the lunches, the food was excellent, a great choice of dishes to cater for all tastes.

The first session I attended was Ted Newards keynote speech entitled ‘Rethinking Enterprise’. Last year Ted spoke about developers needing to find their unique selling point in world of cheap developers. His speech this year started off along the same lines. He asked the question that all developers would like answered… “What do I do to ensure I don’t get replaced by a cheaper developer?” What does this have to do with rethinking the enterprise, I wondered?

We are all programmed to jump to the most obvious solution to a problem. When at school we learn a single subject then get tested on that subject. We learn another subject then get tested on that subject. Even if the questions in our test are different to what we are used to it is a good bet that they are related to the subject we have just learnt about. As adults we attend training courses. After attending a course we return to work with our newly gained knowledge and our boss assigns us a new project. We automatically assume that the new technology we have just learnt about is going to be what we should use to implement this new project. Why else would we have been sent on the course? The same goes for enterprise applications. When someone asks us to design or implement an enterprise application we automatically think J2E and more often than not EJB . Admittedly this is a highly simplified and contrived example, but there is no doubt that we have pre-programmed solutions to problems that we are asked to solve. We may think that we are choosing the ‘Best practice’ solution, however ‘Best practice’ suggests that we have finished and there is no room for improvement. Ted challenged us to rethink this and not settle on the first solution that comes to mind. We should really look for ‘Good practice’ as this allows us room for improvement. This kind of thinking allows us to design solutions that others may not think of and therefore give us that advantage and unique selling point that we need. Don’t just settle on the obvious solution, explore the less obvious and you never know what you may find.

Another interesting and more technical session was on the subject of RESTful services. This session was run by Neil Ford from Thoughtworks. SOAP based web services have been around for a while now and are widely used. This session started off with a brief introduction to REST and its benefits over SOAP style web services. SOAP based web services are often orchestrated using a heavyweight BPEL engine. This often couples together the application providing the SOAP service and the BPEL engine. The BPEL engine must maintain the state of the process, the applications involved in the process may also maintain knowledge of the process state. This is where HATEOAS provides a mechanism to manage the state in the applications that are involved in the process. At its most basic level a REST service request is simply an HTTP request using one of the four HTTP verbs, GET, POST, DELETE, and PUT. These requests are always resource based, so you GET an order, or DELETE an order etc. The parameter string of the request URL contains all the relevant input data. REST and HATEOAS provides the ability for the application providing the service to return the set of potential next links, ie state transitions. The state transitions of the process are stored in the links rather than a heavyweight BPEL engine. A simple example of this idea that we have all seen is a search engine result page. You submit a query to a search engine and are then presented with an HTML page of results. If this were a BPEL process the BPEL engine would know which page of the results you are viewing. If you click ‘next page’ the BPEL engine would know what page is coming next and return that for display. With HATEOAS the links on the page contain the actual next page number in the URL. So if we are viewing page 2 the next page link would request page 3 and the previous page link would request page 1. There is no need for the search engine to know what page you are viewing. The state of your search process is implied by the possible transitions stored in the links, therefore encouraging a stateless approach. HATEOAS may well be the future of SOA that provides an alternative to the usual SOAP based web services.

The final area that I’m going to write about was a session entitled “Software Quality – you know it when you see it” by Erik Dörnenburg. We all want to write quality software, but how do you spot quality software? We often have to work code that was written by someone else, or code that has been around for years evolving as requirements change. If we are working on a new project or legacy code we need to quickly determine problem areas and issues that exist. We need a view of the application. Our introduction to the applications will probably be a diagram consisting of some boxes with lines joining them together, the 30,000 feet view. If we are lucky a detailed design document may tell us what the application should look like, but these are often out of date and lacking in real detail so little use when looking at code quality. Lastly we have the code itself, the 0 feet view. Far too much detail when it comes to understanding an application. What we need is the 1,000 feet view that is generated from the code itself. Erik took us through several visualisation techniques that provided a very fast way of understanding an application. The “Code City ” was probably the most interesting visualisation.

This is essentially a 3D map of the application that allowed us to quickly understand the structure of application. In the above example classes are represented as buildings, while packages are represented as districts. Problem areas are easily spotted. For example a huge building may highlight a huge hard to maintain class. Dependencies between packages could be drawn onto the city allowing us to spot problem areas very quickly. These kinds visualisation give us that 1,000 feet view where we can see potential issues very quickly. As with all these new techniques it is the initial setting up the visualisation that is the time consuming part, but as tools mature this could be the future of metrics and tools such as Checkstyle.

Smart421 normally attend the Websphere User Group, however this is a very specialised event that may not interest many Java developers. I would certainly recommend the JAX conference to any Java developer no matter what level of experience you have. In our day jobs we often concentrate on a just few technologies for several months while working on a project. We don’t get the time to explore technologies, frameworks etc that give us the inspiration to ‘Rethink the Enterprise’ or just give us a head start on our next project This kind of conference is a good way to find out about cutting edge Java technology at a useful level of detail.