Abstract

These pages describe the 'bpm4struts' cartridge. The shorthand 'bpm4struts' stands for 'Business Process Modeling for Struts'. The purpose of this cartridge is to generate Struts web pages from an input UML model in which the flow of the application is modeled.

Introduction

Writing a web front-end for J2EE application can become a really cumbersome and tedious task. Most of the time it is very difficult to start with a good design and keep it, the problem may even become more apparent when multiple developers are working on the same project. In a Struts application more specifically, problems that often arise are: too much data in the session, bad variable names in the pages and in the actions, inconsistent programming style, improper exception handling, hard-coded constants, duplicated code, and the list goes on...

The reason these issues exist is not always because the developers are inexperienced or lazy; the main reason is that it is simply very difficult to keep everything consistently up-to-date. It is very easy to lose track of what is going on and before you know little evil parts of code find their way in, introducing bugs and making maintenance a pain.

It is important to keep an eye on the big picture. Take a look at your application from a distance, maybe you'll spot some design flaws. This brings us to the most common tools for communicating application architectures: the Unified Modeling Language, unfortunately not many people believe in it ... and that's understandable, it can be quite a burden to keep the UML model up-to-date (*) when you are already facing the many issues mentioned above; the Model Driven Architecture paradigm solves this problem elegantly, read on.

(*) This is already where it is going wrong, your model should exist before you even start coding, but since development is an iterative process and changes are often applied in the code first we find ourselves updating the UML model to comply with these changes.

A second comment is that at all times a developer should spend his efforts on the core business of the application, if he's writing an online web-shopping application he should not be worrying about coding connection pooling or a search engine, this should be reused from elsewhere. There is so much activity in the open-source community that this should not be a problem anymore.

So, if it would be possible to quickly generate the desired code from a UML model using coding templates, and to regenerate this code without losing any manually applied changes, one can easily see the benefits: a constant focus on the overall design, the developer can try several different approaches in a short time interval, the developer spends his time on the business logic and not on the technologies used to achieve his goals.

As you will read in this document bpm4struts addresses the majority of these items.

Goal

We aim to have a means of generating a stable and flexible Struts front-end by modeling dynamic business processes from UML. The transformation from UML to Struts should be open enough to allow anybody to easily update this process, for example by simply editing some templates.

Any feature provided by Struts should also be available in the cartridge.

The generated code should be consistent and in-line with the most common best-practices in web development. It must also help the user adding the final pieces of code in order to finish the implementation. Except for the business logic he will need to implement himself, the user should not need to have knowledge of the rest of the generated application, although it can never hurt.

Regeneration of code from UML should not overwrite manually written code. Classes can attain this goal by using a construction such as inheritance. With JSPs we use Tiles to isolate those pieces that need regeneration, anything else remains untouched.

When a complete application has been modeled it should be possible to generate and deploy the application without any further changes to the code. The application should work right-away, this allows the user to test-drive and see if it is what he expected, optionally updating the model where necessary.

Features

Web development

When developing a web front-end you must be aware that it is nothing like your regular Swing/GUI development, such as in a standalone application. The HTTP protocol is stateless by design, while most users want to have the feeling they are in a session or context.

There are many ways to solve these typical problems on the web front-end. Personally, I prefer not to make use of the session in the web container: I like to do as much as possible in the scope of the requests. This has several advantages: bookmarks always work, the back button will not corrupt any session data, etc... This is important to know when modeling for the bpm4struts cartridge, it allows you to look at each use-case separately and treat them as individual processing units. You will also notice you tend to write better code this way.

Unfortunately this will render some features impossible to implement. Using only request scope you will have a problem displaying the JSP pages when you are referring them directly instead of going to an action first. An example of this occurring is when Struts declaratively handles an exception, in this case it needs to directly forward to a JSP page. There are two reasons for this:

1. By calling another action you risk the chance of having another exception, or even the same exception again.
2. It is often simply not possible to determine which was the action that forwarded to the JSP page, maybe there are two, or even three.

Consider this scenario, it might make things more clear:

1. You are on a JSP page with a form
2. Submit the form to an action
3. The action executes and throws an exception
4. The exception is handled by Struts
5. Struts forwards control back to the JSP page to display an error message

What happens if there are beans on this page that cannot be found in the request ? If you want to go to the action prior to the JSP page, are you sure you can always determine which one it is ?

So you see, it is not so evident trying to have all forms in the request scope only. So for this reason I have decided to switch to session scope. This also has some advantages for performance and sometimes it will conveniently prefill input fields from the same use-case. Of course a possible disadvantage is that you might see input field values you are not allowed to see (application security). But this is easy to remedy and will be features in bpm4struts (probably by removing the form from the session once the use-case finishes, by reaching one of its final states; or alternatively, when entering a new use-case all previous form are removed from the session)

Next, we need to consider the communication between the client and the server, what tools to we have at our disposal ? Well, quite enough I must say ... we can use almost any feature we can find in a rich standalone GUI client: radiobuttons, textareas, hyperlinks, tooltips, and so on. So it would be nice if we can render the appropriate input elements for the request parameters sent from the JSP page.

Struts

In order to adhere to the spirit of Struts web development I am trying to attain at least the same strict requirements of its MVC implementation. As opposed to earlier version of this cartridge, you will only need to model the Controller class, the Views and Models are implied by the dynamic processes.