Last month, 52°North staff visited the Schloß Eringerfeld for our yearly retreat. We wracked our brains from thursday through saturday, targeting 52°North road maps and aligning common goals and strategies for 2013. We braved the cold and snow to discover hidden archery talents and topped off the event with a medieval banquet in the castle dungeon! All in all it was a very informative, productive and constructive event.
This is my first blog in a long time. It will be the first in a potentially long series and the subject will be quite different from that of my series of blogs in 2011/2012. In 2011/2012 I mostly wrote about functionality in ILWIS, i.e. the development of the new map window and all the visualization stuff that spawned from it. I probably will still write about that (work never stops), but my main focus will now shift to programming – programming for ILWIS NG (or ILWIS-Objects as people suggested to me).
In the first blog series, I tried to explain what changed in the 3.8 version and why it was so fantastic (!?). I consider that done now. Sure, new things will still be included in 3.8 and old things will be improved/resurrected or whatever, however, it is unlikely that you will see such sweeping changes as the 3.8 introduced. Since 3.8.3 is now more or less finished and a big reference document about the map window has been written, it is time to shift direction.
ITC is a partner in the European Marie Curie Initial Training Network “CHANGES”. The CHANGES network will develop an advanced understanding of how global changes (related to environmental and climate change as well as socio-economical change) will affect the temporal and spatial patterns of hydro-meteorological hazards and associated risks in Europe; how these changes can be assessed, modelled, and incorporated in sustainable risk management strategies, focusing on spatial planning, emergency preparedness and risk communication.
One of the main components of the project is the development of a Web-based Spatial Decision support System to analyze the effect of risk reduction planning alternatives on reducing the risk now and in the future, and support decision makers in selecting the best alternatives. ITC is responsible for the development of the data analysis modules within the SDSS.
Preliminary Remark: This blog post targets Open Source developers and will basically cover technical details.
Automated Integration Testing for Java Web Services is an important pylon to ensure the stability of a web service and in particular its internal workflows. It is a very convenient way to ensure that the server is reacting just as expected in a set of pre-defined situations in terms of responses to specific requests. An easy way of defining integration tests is to provide a certain set of fully-defined requests (POST, GET, …) and corresponding responses. However, if you also are maintaining a client framework or library dedicated to that service, you are in the sweet situation of being able to kill two birds with one stone:
End-To-End Client-Server Integration Testing.
This is the first of two blog posts on End-To-End Integration Testing. For now, I am focussing on the Maven project setup. The follow-up will provide some insights on the actual implementation of integration tests – the client side.
In the following I will try to provide a guide on how to incorporate an integration testing component into your existing Maven-3-managed web service. I will use the 52°North Sensor Event Service (SES, server component) and the 52°North OX-Framework (OXF, client library) as a hook for the following sections. Knowledge of the following topics is helpful for understanding the article:
We will cover all needed steps to enable integration testing in your web service project. In particular, details on preparing a temporary webapp, reserving network ports dynamically, bootstrapping a servlet container and the actual execution of the integration tests will be illustrated.