The World Wide Web had barely appeared when people were looking to Web-enable the relational database (RDB). The...
first approach was known as CGI (Common Gateway Interface) - it was basic and low-performance. Then, the Java app server came in quickly as a means to connect an RDB with a Web front end. Java was so prevalent; it allowed Sun Microsystems to claim it put the "dot" in "dot.com."
Web services came along as well. Obviously there was value to connecting, for example, a mainframe-based transactional car rental system with an Expedia-style Web front end. But, for people over-imbued with conventional wisdom, the database and the transactional system remained the center of the real game. Much Web services development, in retrospect, was unnecessarily beholden to old familiar RDB-centric architecture.
Enter Google, Amazon and a host of other successful Web startups. These companies found real customers. They also found real limitations with relational databases. They also invented cloud computing. Today, the major distinguishing characteristic of cloud computing is a general drive to reduce the role of the RDB. The RDB has a future, of course, but it shows signs that it is not the be-all and end-all.
The new Web-based companies had little vested interest in conventional wisdom. To them, the relational data base did not look like the way to do the Web. Instead they spawned non-SQL software like Cassandra DBMS, as well as the MapReduce and related Hadoop distributed application frameworks. Some new Web businesses (think "Facebook") place messaging middleware at the center of their architecture, shunting the database to something of a side role. Conventional wisdom got a kick in the pants.
With conventional wisdom on the run, we have entered a new era of software architecture. Lightweight Web application frameworks have rocketed past overly cumbersome object component containers. On the portal front, we see enterprise mashup APIs and REST reworking the ground rules of architecture.
Today, there is much talk about the future of Java. Some pundits suggest it is too infrastructure-oriented, and too complicated to meet the needs of the enterprise. We as an industry would do well to be sure to take off the conventional blinders when analyzing the issue. It may be the case that Java will continue to thrive but that programmers' ability to use it in conjunction with other languages (Clojure? Scala? Python?) will become key.