“In DB2, or any other database, you can control access through grants to particular users.” — in my experience in enterprise applications (and that of all my collegues, based on discussions and papers written & reviewed by the community), it is very rare for DB admins to set up per-end-user access. WAS guidelines recommend a single userid/password for an application (often for an entire suite of apps) as the typical case. Also, r/w vs. r/o access isn’t enough since the vast majority of secured enterprise data must be secured from read as well (do you want your neighbors reading your bank statements?). There are indeed alot of control points but DB admins and their executives don’t want to use them. That’s why we have LDAP and ActiveDirectory. Getting very clever (and more verbose in your JSP logic) means more logic that is difficult to debug using today’s IDEs (anyone who has tried to debug JSPs would agree — if anyone doesn’t pls chime in). Until there is a revolution throwing out MVC as the most common design pattern there will be no motivation for IDEs to make this any easier.

“while a consuming application necessarily loses… You could serve different formats to each” — my point is that putting such new function in the model (outside JSPs) with the minimum JSP view logic means that access by consuming apps is free – you don’t have to reimplement your SQL and related logic in a second place the apps can reach. The additional cost is very minor, only an extra method call or two from the JSP instead of the logic being inline. If this was “bolt[ed] on separate to the existing application” it’s still a JSP and thus not accessible to model (ie., plain Java) code; implement it in the model and its accessible to both.

“cheaply prototyping ” — honestly I don’t see this as any cheaper to implement than doing it as MVC, except for those 1-2 method calls I mentioned. A prototype MVC implementation is fast because you don’t add in the full set of error checking, edge functions, etc. You still end up with the layering you’ll use in the final production-ready feature (assuming you’re adding a feature to a mature app which good layering standards already) and only have to add code to the existing classes. If you prototype as JSPs then you must create the basic classes for layering and refactor all your JSP logic into them. I happen to currently have a customer (not the first I’ve seen) that took a variation of your “all in the JSP” approach and they experienced exactly this no-faster and hard-to-debug situation. SO I’m saying you can definitely cheap-prototype to validate a need and still stick with good MVC.

“About your later point regarding caching” — I am talking about data-level caching (Dynacache dynamic page content caching is great, but isn’t always the best choice). Dynacache command caching, for example, assumes you have MVC and actions/commands; it would be really messy stuffed inside a JSP. Beyond that are the more recent techniques (still 8-10 years old) of caching at the data layer (after you do a DB query and turn the data into a Java object, you caching it to avoid repeating the DB query). This includes simple single-JVM caching using java.util.Map and cross-JVM caching products like WebSphere Extreme Scale or Coherence. You also miss out on using Hibernate or the Java Persistence Architecture (JPA) feature in WAS to automate your DB access – as well as the caching points built into these frameworks. These are the sorts of caching technlogy you miss out on if you put your data access logic in a JSP (to be precise, it would look WAY WAY UGLY to stuff this into a JSP). Yet the primary benefit of JPA is to speed up development of data access logic (but in a production-ready way when you later add query tuning and other fine adjustments). Using the PreparedStatementCache does greatly speed up making a DB query a second or nth time, but it can’t compare to avoiding the query altogether by caching the data. About 70% of my gigs over the last 2 years have been involved at least partially with going beyond query optimization into actual data caching. Ask other currently-practicing consultants and I bet you get a number more like 40% (since caching is a special skill area of mine) but that still clearly shows that most apps benefit from some form of caching beyond DynaCache static and dynamic content caching.

“best tool for the job” — I totally agree with you, as I am also a pragmatist. We seem to only disagree about the relative benefits and drawbacks of SQL-based tags in JSPs. I do fully recognize the one inescapable benefit of putting the entire function in a JSP – that JSPs are easier to upload on the fly (on the sly??? ;-) into a running application than non-JSP Java classes are. However, that is really a process problem – there SHOULD be a way in any web application environment to easily try out potentially useful new function. It is totally technically possible, in several ways. It will always be controlled and that’s as it should be – you can’t have any developer with wild hair adding function to a public web app which is the public face of a company. If the only reason to put business logic into a JSP is to hack around a self-defeating corporate IT policy then call it a hack and perhaps use the above drawbacks to justify fixing the policy so you can prototype the way you should.

Thanks for the comments. Don’t worry, I don’t take them as rude. :)

Before I address your points, let me just re-iterate a passage from the post. This should reinforce my view that this should be considered a temporary and unorthodox option – based on something that’s available in the spec – not necessarily a best practice. The goal is to provide some extra, low cost functionality quickly to justify further development using the proper approach.

Of course, the flip side is that you’ve [provided data-powered functionality] outside of your application framework and may have circumvented some well-intended best practices. However, you may to prefer to think of this approach as a temporary, low-risk way to share the data available to the users of your application in novel ways that may justify investing in the development of longer term solutions.

So in no way is this post meant to disparage architectural best practices in JEE development. I find it complementary to – and doesn’t compete with – our Struts and Spring MVC applications in production.

In fact, it even becomes a necessary measure when your application is deployed to a hosting center that requires 4 months and $20k to deploy an updated EAR file, versus promoting a single JSP on demand.

On to your points;

To answer the first one, about security exposures. This is indeed a low risk approach. There is nothing in the tags that implies that the data source you are accessing from the tags has unlimited privileges on the database.

In DB2, or any other database, you can control access through grants to particular users. Or even set up views to limit their access to the underlying table structure. In WebSphere, or any other app server, you’ll then associate the user id to a data source and make it available in your deployment descriptor to the Web application. So there are a lot of control points here.

For example, you might have one read-write JNDI resource for your business logic, and another read only or restricted access enforced by the database and optimized through several modifications to your queries, such as those that increase concurrency through isolation levels.

To address your second point, I don’t understand why doing this implies that the end user gains while a consuming application necessarily loses… You could serve different formats to each, or just bolt this on separate to the existing application without upsetting any existing interface.

And what if one user or another now wants the same access to the data you’ve just freed up… that’s the point of cheaply prototyping in order to validate a business need and justify new development to meet the requirement.

About your later point regarding caching, can you provide some more detail here how this defeats the cache? These JSPs are compiled like any other into servlets, and you can still use WebSphere’s DynaCache to set a policy for these URLs. Using prepared statements and the proper read-only optimization in your queries makes this as efficient as any other data access method you could deploy in a Web app.

As for ColdFusion… I refuse to defend that platform, and I feel your pain… What’s the sounder platform you suggest?

In any case, my experience has shown me that it’s wisest to choose the best tool for the job, even if that means integrating several platforms (e.g., WebSphere and PHP) or breaking down your system requirements into manageable chunks that can have their own independent technology implementation and link them together with an SOA, or even supplement an MVC architecture with good old functional, type one JSP scriptlet pages.