(this is “in progress” – feel free to comment, etc.)

One of the most exciting things we see people doing with the SASH stack is using it in combination with Tomcat to create a platform for full-blown development of scalable web applications in Java without the heavyweight complexity of J2EE. This new alternative to web development, although not as “sexy” as Ruby on Rails, seems ready to have a much larger impact on how large, scalable web applications are architected, implemented, and run.

One great thing about SASH is that its component technologies were designed to solve real-world problems. Take Spring, for example. It is primarily developed by Interface 21, a consultancy in the UK that builds Java applications for large financial services firms. The origins of Spring lie in the needs that Interface 21 developers saw for implementing their projects for their clients – and the weaknesses in what they got “out of the box” from J2EE implementations. Spring, and other projects like Beehive, have helped drive the move towards putting logic in Plain Old Java Objects (POJOs)

I was talking with an analyst about this the other day and he asked “Who is going to use SASH? Is the architects who love J2EE? or is it the “get it done” developers who slap together the tools they need to accomplish the job? My answer was that we’re seeing SASH bring together the two groups – architects understand that a big part of their role is to enable and empower the “get it done” developers (and SASH certainly does that) but at the same time they see the architectural value in a more POJO-centric model for application architecture. They realize that EJBs are often overkill. We’re seeing SASH help build bridges between central IT architects and line-of-business engineers.