In contrast to classic forms, wizards have more than one form view page. Therefore, there are various actions instead of one single submit action:

• finish: trying to leave the wizard successfully, i.e. performing its final action, and thus needing a valid state;
• cancel: leaving the wizard without performing its final action, and thus without regard to the validity of its current state;
• page change: showing another wizard page, e.g. the next or previous one, with regard to “dirty back” and “dirty forward”.

In this article I want to focus on pages, how to set them up, expecially in the uncommon situation in which you don’t know exactly the number of pages you want to put in your wizard before running the application.

Every Spring manual would suggest you to put WizardFormController’s pages in the Spring XML configuration file, and actually this is the best way to set up your pages. Let’s consider the following configuration:

We have put a property named pages inside myWizard.html bean, in which we listed the page values. Each value is used as the name of the view inside your jsp folder.

And now the wizard form, you can set it up for your needs.

Finally the wizard controller.

What if, for some reasons, you need to create or edit your wizard page list at runtime? Let’s face the problem.

First of all, you can override the XML configuration through the setPages method. The following example replaces the page list specified in the XML file with an identical one but that has been built at run-time in MyWizardFormController constructor.

This doesn’t help much: we moved the configuration outside XML (that’s a bad thing) but we still have a fixed number of pages with fixed values.

Let’s consider an application in which the page values are the request parameter keys for the first step (i.e. _target0). We might call setPages inside an overridden method used before the wizard controller accesses to page list, such as the getInitialPage method.

In this way, as soon as myWizard.html bean is invoked by clicking on a link (i.e. GET http request) or submitting a form (i.e. POST http request), the page list is dinamically built starting from request parameter keys. This would be more useful if you decide to use request parameters values, or attributes.

For my purposes I used request parameter keys retrieved from a form submission in order to run an unordered set of pages and reporting each result (i.e. validation) in the final step.

Its name is Ovi Store, has been announced at the Mobile World Congress 2009 (Barcelona) in February, and on May 26 it went live for all Nokia users in the world. More than 50 Nokia devices were compatible with the service from day one and Nokia estimated that around 50 million people with Nokia devices would be able to benefit for Ovi Store. Initial number of applications was 20.000 and new applications creation is propelled by an high percentage of money going to developers. Moreover the Nokia N97 will be the first to come out with Ovi Store pre-installed.

The Global Intelligence Alliance Group conducted an interesting analysis on  mobile market places. Different market places have been compared in terms of:

1. time to market
2. the ability to attract developers
3. the rate of device adoption
4. an efficient interface and user experience
5. having a critical mass of attractive applications.

to get the following rankings table:

Source: Global Intelligence Alliance. Points are allocated as follows: 2 – strong, 1 – medium, 0 – weak based on assessment/expectations of all application stores along the parameters.

It’s interesting to note that Nokia’s rank is two points lower than iPhone Apps Store’s, but equal to Android Marketplace’s. Further information in the Global Intelligence Alliance’s article.

What distinguish Nokia Ovi Store from the other marketplaces is the device and application heterogeneity Nokia had to manage and offers. Despite iPhone Apps Store, that is clearly made for one phone, Nokia Ovi Store covers more than 50 Nokia devices, Series 40 and Series 60 included, and because of this for each mobile application the Ovi Store needs to indicate the device compatibility. Moreover, even if every application you can find inside the Ovi Store behaves and looks like it has been developed using the same technology, the same programming language, it doesn’t ! In fact, a Nokia application you download from Ovi Store might be:

1. A Nokia Symbian Mobile Application
2. A Java Application (MIDlet)
3. A Nokia WRT Widget

This might be seen as an advantage for the developer because she/he has the chance to choose the technology which likes more or which better fits to application features or customer requirements. And maybe it is, we’ll see what happens in the next few months.

However in this post I just want to show you my new widget-based and social network-oriented personal web site.

http://www.francesco.iovine.name/

To achieve this, I used the badge creation feature provided by each social network I’m on, which are Facebook, Flickr, Twitter and LinkedIn. In details:

• Facebook Badges. Highly customisable but doesn’t work so good yet. In my case the HTML code generator created a wrong code, so I had to pick up HTML code directly from the preview badge ! ^^’
• Flickr Badge. Available both in HTML and in Flash. Highly customisable, works fine !
• Twitter Badge. The HTML badges are customisable only via CSS stylesheet. Flash badges are both interactive and display-only, pretty but almost not customisable.
• LinkedIn doesn’t provide a badge creation feature, so I used a linked banner.

In order to create widgets from my blog feeds, I used CustomRSS, an highly customizable Google Gadget.

UPDATE 21/06/2009: I added graphical effects to achieve a presentation fashion. I used JQuery effects, in particular fadeIn, fadeOut and animate functions.

UPDATE 04/07/2009: CustomRSS doesn’t work properly anymore, therefore in order to republish my feeds as HTML I used Feedburner BuzzBost at its place.

It was a very interesting seminar due to the fact that software architecture was still something vague for me (i.e. a computer engineering student much interested in software engineering but who has never handle with projects big enough to need a significant effort in making the architecture).

In his seminar, first of all Kruchten tried to give a definition of Software Architecture coming to the following conclusion:

Software architecture encompasses the significant decisions about:

• the organization of a software system,
• the selection of the structural elements and their interfaces by which the system is composed together with their behaviour as specified in the collaboration among those elements,
• the composition of these elements into progressively larger subsystems,
• the architectural syle that guides this organization, these elements and their interfaces, their collaborations, and their composition.

Software architecture is not only concerned with structure and behaviour, but also with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints and tradeoffs, and aesthetics.

Although this definition of Software Architecture seems to be comprehensive, surely it is not so easy to understand at the first reading. A simpler definition could be the following:

Architecture is about making decision.

Then Kruchten focused on what architects actually do.

The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark.

Architects should spend their working time in the following manner:

• 50% Architecting (design, validation, prototyping, documenting, etc.)
• 25% Getting input (from user requirement, other architecture, technology)
• 25% Providing Information (communicating architecture, assisting other stakeholders).

The right balance among these activities is very important in order to not fall in typical situations in which architects don’t know anything about existing technology, or don’t communicate their work to designers.

It’s clear that decision is the key word for Software Architecture, therefore Decision Models, Decision Visualizations and Design Decision Capture Mechanisms are the key tools for architects. Refining models, languages and mechanisms concerning decisions is the purpose of Software Engineering Research in this area.

«If you ever admired those colleagues who stayed in office for more than 10 hours day by day, you should consider the fact that after a specific amount of work time bug rates increase dramatically and work results tend to reach lowest levels. Thus, working too hard for a long period of time could even have a negative effect.» Michael Stal

PASSI (a Process for Agent Societies Specification and Implementation) is a step-by-step requirement-to-code methodology for designing and developing multi-agent societies integrating design models and concepts from both OO software engineering and artificial intelligence approaches using the UML notation. The models and phases of PASSI encompass anthropomorphic representation of system requirements, social viewpoint, solution architecture, code production and reuse, and deployment configuration supporting mobility of agents. The design process with PASSI is supported by PTK (PASSI ToolKit) which is composed by an add-in for Rational Rose and a tool for reusing patterns of agents. [The PASSI Design Process]

I have recently followed the PASSI process to develop an Architecture for Context-Dependent Information Systems, as a component of the middleware layer (the layer between the transport and the application layer). JADE has been the framework I used to work with agents.

JADE (Java Agent DEvelopment Framework) is a software framework fully implemented in Java language. It simplifies the implementation of multi-agent systems through a middle-ware that claims to comply with the FIPA specifications and through a set of tools that supports the debugging and deployment phase. The agent platform can be distributed across machines (which not even need to share the same OS) and the configuration can be controlled via a remote GUI. The configuration can be even changed at run-time by moving agents from one machine to another one, as and when required. The only system requirement is the Java Run Time version 1.4 or later. [JADE Homepage]

I must say that I’m impressed with how much the PASSI process can be so powerful in its semplicity. Have a look at the PASSI Home Page to find out how the steps you have to follow are easy to understand and to put in practice. The partition in five models allows designers to look at the multi-agent system in different ways. The models are: System Requirements Model, Agent Society Model, Agent Implementation Model, Code Model, and Deployment Model. For more information have a look at the PASSI lifecycle.

Looking at the documentation, it would seem that PASSI is a waterfall process, but it is not. PASSI is iterative, sequential and top-down, as the authors (M.Cossentino and C.Potts) write in paragraph 2.2 of the research paper about it. There are two kinds of iteration in PASSI. The first one is related to requirement elicitation and involves dependencies among the System Requirements Model, the Agent Society Model and the Agent Implementation Model. The second type of iteration is related to Multi-Agent System Implementation and takes place inside the Agent Implementation Model in the manner shown in figure.

PASSI has been very helpful to me for developing a well-structured agent-based software application. In particular the Deployment Model helped me to get the picture of the software I was on the point to develop. I’ve been run the Deployment Configuration phase (the only one of Deployment Model) during the phases of Agent Implementation Model because I needed to understand how effectively components (placed in different containers) could communicate among themselves. Moreover, since the application I developed implied agent mobility, I needed some deployments diagrams to describe any constraints on migration and mobility, in order to describe the behaviours of module providing mobility.

PASSI is without doubt a good process to follow but the online documentation about iterations and phases overlap is not clear enough. That’s why I have just written this post!

“WEP suffers from two fundamental deficiencies: it was poorly designed and it was poorly implemented. Other than that, it’s fine.”

H. Berghel and J. Uecker. Wireless Infidelity II: Airjacking. Communications of the ACM, Volume 47, Issue 12, pages 15-20, December 2004.