Introduction

Why Redmound?

If you are looking to do web application programming in Java, you have a very large number of choices these days. In fact, there are so many web application frameworks now that it has become somewhat of a joke. One blog site on the Internet poses the question: How many Java web frameworks can you name? The answer they show looks like this:

Frameworks, Frameworks Everywhere

Why “Reinvent the Wheel”?

In light of this, you may be wondering “What good is another web application framework?” Indeed. Why “re-invent the wheel?” One snappy comeback to that old saw is: because this time we could make it rounder!

But it was not simply a desire for higher quality that drove the creation of Redmound. Even with so many options, there really is no web toolkit which fills exactly the niche that Redmound fills. In fact, Redmound is quite unlike each of the frameworks above.

Here is a comparison matrix with some favorite frameworks:

To understand why Redmound is so different, it may help to understand the motivations that created it.

Motivations

Most existing web frameworks provide weak to non-existent support in managing server-side state

This normally means lots of ad-hoc code in web applications dealing with the gory mechanics of state management. While Redmound will not allow you to stop thinking about server state, it goes a long ways towards making it easy and often transparent to manage that state.

In Redmound, all server side state is automatically managed. You will never directly use an HttpSession object or similar wrapper to store state. Instead, state is associated with special session and security framework Apache Shiro. Apache Shiro offers something unique in the world of security frameworks: a complete enterprise-grade Session solution for any application, from the simplest command-line and smart phone applications to the largest clustered enterprise web applications. This has large implications for many applications - until Shiro, if you required session support, you were required to deploy your application in a web container or use EJB Stateful Session Beans. Shiro's Session support is much simpler to use and manage than either of these two mechanisms, and it is available in any application, regardless of container. Here is a list of the most desirable features provided by Redmound session support:

• POJO/J2SE based (IoC friendly) 
• Easy Custom Session Storage
• Container-Independent Clustering
• Heterogeneous Client Access
• Event Listeners
• Host Address Retention
• Inactivity/Expiration Support
• Transparent Web Use 
• Can be used for SSO 

You will also find that this well-structured server state makes it very easy to deal with the dreaded “back button problem”. In fact, Redmound has a generic and robust solution which can identify and expire browser-cached pages that have become stale due to structural changes to the model of a component on the page.

Most existing frameworks require special HTML code

JSP is by far the worst offender, allowing the embedding of Java code directly in web pages, but to some degree almost all of the frameworks from the list (except Tapestry) above introduce some kind of special syntax to your HTML code.

Special syntax is highly undesirable because it changes the nature of HTML from the kind of pure-and-simple HTML markup that web designers are familiar with, to some kind of special HTML. This special HTML can be more difficult to preview, edit and understand.

Redmound does not introduce any special syntax to HTML. No “special sauce” in your HTML means designers can mock up pages that you can use directly in development. Adding component modules to the HTML is as simple as setting the component name attribute. And you can then give the HTML back to your web designers knowing that they can change it with confidence.

Redmound, more than any other framework gives you a separation of concerns. Web designers can work on the HTML with very little knowledge of the application code (they cannot remove the component name tags and they cannot arbitrarily change the nesting of components, but anything else goes). Likewise, coders can work on the  component modules that attach to the HTML without concerning themselves with what a given page looks like. By not stepping on each other’s toes, everyone can get more work done.

Existing frameworks are not easy

Most of the existing toolkits have poorly defined or non-existent object models. In some cases, the model is defined using special XML syntaxes. The syntaxes may be so cumbersome that special tools are required to manipulate all the configuration information. Since these toolkits are not simple Java libraries you may or may not be able to use your favorite IDE tools such as editors, debuggers and compilers.

Redmound is all about simplicity. There are no configuration files to learn in Redmound. Redmound is a simple class library with a consistent approach to component structure. In Redmound, your web applications will have web pages as web pages. If you know Java and html, you already know a lot about Redmound. If you also know Java Script, you are master.

Existing frameworks inhibit reusability

Tapestry and JSF at least have component models that allow reuse, but you are likely to find that it is not particularly trivial to do, at least when compared with Redmound. Redmound has been explicitly designed to make it very, very easy to create reusable components. It’s surprisingly simple to extend existing components and to make compound components such as a SignInPanel or AddressForm. It is also relatively easy to create components that exploit new features of browsers. Components in Redmound can be packaged up and reused by simply dropping them in your lib folder - no configuration necessary!

Existing frameworks incapable of managing run time 

Existing frameworks just focus on development phases. 

Existing frameworks have troublous configuration process

Existing frameworks does not cover latest best practice

Redmound is combination of enterprise application experience, best practice sub-frameworks, design methodology and futuristic approaches. Redmound is a model driven web framework which definitely makes it unique. Developers design reusable web component models. Models can communicate each other over service bus. Business is modeled in middleware and mapped to required view and services. Redmound has MVC structure in general and presentation side is native web 2.0, having MVVM ajax binding for web developer toolkits like JQueryUI, Kendoui, Wijmo, Bootstap etc. This feature allows to develop very rich desktop applications. Power users can enhance application in a way that is not bounded to limit in the development processes.

In Redmound, sessions are separated from services, which increases service reusability and quality of overall architecture.  Sateless services can easily be clustered, relocated and replaced. 

Web programming should be fun!

This is my most personal goal for writing Redmound . None of the existing frameworks are appealing to me in terms of intuitiveness, quickness, ease of development, etc. It is my hope that Redmound represents a significant step in the direction of making web applications easy and fun to write.

Goals

Coming from these motivations, the following goals for Redmound emerged:

• EASY (SIMPLE / CONSISTENT / OBVIOUS)

  • POJO-centric
  • Server code written in Java, client code written in html / java script 
  • Minimize “conceptual surface area”
  • Avoid overuse of XML configuration files
  • Fully solve back button problem
  • Maximum type safety and compile-time problem diagnosis
  • Maximum diagnosis of run-time problems
  • Minimum reliance on special tools
  • Components, containers and conventions should be consistent

• REUSABLE

  • Components written in Redmound should be fully reusable
  • Reusable components should be easily distributed in ordinary library files

• NON-INTRUSIVE

  • HTML or other markup not polluted with programming semantics
  • No special tagging construct in markup
  • Compatible with any ordinary HTML editor
  • Easy for graphics designers to recognize and avoid framework tagging

• SAFE

  • Code is secure by default
  • Only explicitly bookmarkable links can expose state in the page or URL
  • All logic in Java with maximum type safety
  • Already integrated with Apache Shiro security

• EFFICIENT / SCALABLE

  • Efficient and lightweight, but not at the expense of other goals
  • Clustering through sticky sessions preferred
  • Clustering via session replication is easy to accomplish and easy to tune by working with detachable models.

• COMPLETE

  • The Redmound team is committed to deliver a feature complete, ready-to-use framework for developing Java web applications. The current team consists of a group of experienced programmers, some of which were active on some of the other frameworks currently in use in enterprises, and all of which have extensive experience building large scale Java web applications. We eat our own dogfood, and will thus work on Redmound from a framework user’s perspective.