“Model 1” & “Model 2”

This post is part of The Software Architecture Chronicles , a series of posts about Software Architecture . In them, I write about what I’ve learned about Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

Java Server Pages (JSP) is a technology, a scripting language comparable to PHP, ASP, or even Python, that is used to create server-side pages interpreted by the JVM and which can use Java objects.

The first JSP specifications, published in 1998 by Sun Microsystems, defined two ways of structuring an application so that the presentation logic would be decoupled from the business logic, and even the use cases, in an HTTP request/response paradigm.

Some consider these “Model 1” and “Model 2” the first tries at adapting the MVC pattern, originally intended for a context of desktop software development, to the web HTTP request/response paradigm.

Model 1

The first proposal of the JSP spec. v0.92 , was to use JSPs as the only presentation artefact, which would contain all the presentation and use-case logic.

“Model 1” ( JSP spec. v0.92 )

This was probably a good enough approach for most use cases at the time as most of the web was composed by simple dynamic pages, not by complex web enterprise applications as we know them today.

Model 2

The second proposal of how to use JSPs was intended for what was regarded back then as complex web applications. Keep in mind, however, that nowadays web application scale and complexity is quite higher.

“Model 2” ( JSP spec. v0.92 )

In “Model 2”, an HTTP request would reach a servlet which would interpret the HTTP request, execute some use case logic using Java objects and EJBs (repositories), gather the resulting data and pass that data onto a JSP which would render the page to be sent back to the client. In “Model 2” the JSPs are used exclusively as a template engine.

In 1999, Govind Seshadri published an article where he maps “Model 2” to MVC:

the Controller would be the servelet, which controls what should be done with the user request;
the View would be the JSP, which determines what is shown to the user;
The Model, both in MVC and in “Model 2” refer to the whole of the Domain Model.

My take on these patterns

As a curiosity, “Model 2” was actually the first version of “MVC” that I’ve learned, not so long ago.

In the end, depending on the scope and requirements of the project at hand, both approaches are still usable today.

That being said, I think that for today’s web enterprise applications we need something better. The problem I see with both patterns is that they don’t respect the Single Responsibility Principle.

When it comes to “Model 1”, I hope that the mixed concerns are clearly visible to everyone: We would be mixing templating logic with use case logic.

Regarding “Model 2”, I see both the View and the Controller as belonging to the Presentation layer, however, Govind Seshadri makes it clear that “ Model 2 architecture should result in the concentration of all of the processing logic in the hands of the controller servlet “, although the Domain logic is outside, in Java objects and EJBs.

This means that the “Model 2” Controller contains the use-case logic, which belongs in the Application layer, not in the Presentation layer.

For example, if we would want to trigger an existing use case from an event, we would need to duplicate the use-case logic (already existing in a controller) in an event listener and that is a big no-no because it leads to harder maintainability and can lead to inconsistencies throughout the application (bugs).