Take 60 minutes to understand the Power of the Actor Model with "Designing Reactive Systems: The Role Of Actors In Distributed Architecture". Brought to you in partnership with Lightbend.

Today we will finish (for now) our most recent iteration of our Shape Calculator component (or service, if you will). We have been on a long journey to this point. Once we are done, we will move onto:

SOAP services.

REST services.

Web application clients for both of the service types

Securing the services.

Review

In the previous articles, we built the Spring MVC application and exposed most of the operations of the Shape Calculator. We are only missing one major task — adding a <form> so we can create new Calculation Requests. We also need to add a button so the application will actually perform all of the requested calculations. And finally, we need to clean up the code a bit.

Latest Code

In our journey, we have kept the Shape Calculator as a seperate Eclipse project. In turn, other projects (the command-line apps, and this web-enabled app) depend on the Shape Calculator.

Go here for the web app project code. And here is the latest code for our component or service, that is used by the above web app.

Add Button and Code Clean-Up

Let's get the easy stuff out of the way first. The previous article went into some detail what was required to add button to the JSPs. We're just going to repeat that here.

Test Setup

Since we are not yet able to add new Calculation Requests via our web app, we need another way. Take a look at previous articles where I used the command-line application we built to add the desired information, so we can then test this web app.

The test setup goes as such:

Via command line app: Request a few calculations — these will become Pending Requests.

Via command line app: Run the calcuations — this will create the Calculated Results (and empty the Pending Requests).

Via command line app: Request another set of calculations.

Test Run

Via this web app, select to view Results, you should see the first list of Calculated Results.

Click the new "Run All Pending Requests" button.

Observe that the original Calculated Results list grows to include the new batch of Pending Requests.

Here is my first batch of Pending Requests that were run (command-line) and are now Calculated Results:

And here is the updated list once I queued more requests (command-line) and clicked the new "Run..." button:

Code Clean Up

We have the following duplicated in several of the JSPs. We want to locate them in a single place:

RequestResponseController

There are several ways to accomplish dealing with a form that contains some drop-down lists. Here is just one way.

I chose not to use that way. One thing I decided not to deal with was a drop-down that had no value selected. So, really, the only possible user-entry error to deal with is the "dimension" value.

There are two possible errors:

A negative dimension.

A non-numeric dimension.

I handled each differently, if only just to show different ways of doing things.

And that brings us to exception-handling.

Exception Handling

There are many good articles on handling errors inside Spring MVC application. It can get pretty elaborate. One key idea is to keep exception-handling separate from business logic.

For our purposes with this application, we didn't go crazy. We kept it simple. I added just three exception handler methods and placed them in the controller. In a more complex web application, with multiple controllers, we wouldn't necessarily do that.

Like I said, you can get elaborate. But these three served our purposes well-enough.

There is a BindException handler — this will occur if a user enters a non-numeric dimension.

There is (our own custom) CreateException handler — this can occur anytime the Shape Calculator's queueCalculationRequest() hiccups, and one certain occurrence is if the user enters a negative dimension.

And finally, there is a catch-all Exception handler — complete with its own error.jsp.

You can view all the code via the links at the end of this article.

Here are some screenshots of good requests and bad requests.

I left the Exception class in the error message in case there might be another type of error. I didn't want any exceptions thrown during the queueCalculationRequest() to be handled generically and the user land on error.jsp. And that way, we can hope to continue displaying the <form> so the user can re-try.

Conclusion

There are many improvements and different ways of doing this web application (as well as the underlying Shape Calculator service/component). For example, the entire implementation employs a heavy use of @Autowired, and assumes that everything (such as the database) will be running. Using @Autowired is cool and seems simple, but with a large, complex application, with dependent projects, it might get out of hand.

But the application as-is works well enough for our purposes. (Your boss got tired of waiting for you and said "we need to deliver SOMETHING".)

We have concluded with this iteration of our Shape Calculater with a simple web application.

Next Steps

We are going to move on and explore being able to expose the Shape Calculator as a SOAP web service.

Latest Code

You can obtain the latest web app project code from here. And the latest code for the underlying Shape Calculator service project is here.

Stay tuned for the next article! We begin our web service.

Learn how the Actor model provides a simple but powerful way to design and implement reactive applications that can distribute work across clusters of cores and servers. Brought to you in partnership with Lightbend.