Dec 14

Spring 2.x: Two pain points solved

Java, Lightweight Containers, Tech 23 Comments »

It has been great to hear about the new Spring 2.0 features. There are a few much needed ones, but I was particulay interested to see solutions to pain points that I currently have:

Scoping

I discussed cleaning up scoping with JSF and Spring. The ugliness of having a jsf:scope attribute added via schema, and generated files is no more.

Spring 2.0 supports richer scopes, including web based ones (http session, request, etc) ThreadLocal, webflow conversations, and others. Being able to set the scope to these high level abstractions is needed.

Injecting Domain Objects

I run into, and need to use custom code for this one all the time. I want to inject a lot of the objects that I work with. One of the issues is that you want Spring to be in charge of the objects that you with to inject.

A common area in which this isn’t the case is when you get objects from your persistence store (e.g. hibernate). Having to have routines takes these objects and inject them is a pain, as we want this code hidden.

This is where Spring 2.0 comes into play. It allows you, via AOP, to go into these domain objects and wire them up correctly.

Very, very, nice.

Sep 25

War of the Web: Revenge of the Dynamics

Ajax, HTML, Java, JavaScript, Lightweight Containers, Microsoft, PHP, Perl, Ruby, Tech, UI / UX, Web Frameworks 933 Comments »

As I was watching “24 hour party people” on DVD, I heard the main character talk about the ebbs and flows of the music business. He is talking about the scene in Manchester at the end of the 70’s, and into the eighties. Moving from Joy Division to Happy Mondays and New Order.

I think that we are in a new chapter for the web, and as is often the case, the wheel of time is repeating history for us.

There are a few dimensions to the current war though. They are on the client side (DHTML Ajax vs. simple HTML vs. Flash/PDF vs. XAML) and on the server side (Rails vs. Java vs. PHP vs. .NET).

Let’s start at the beginning.

Perl: Birth of CGI

Do you remember how the web changed as it moved from static HTML connected content to dynamic websites? That came about due to CGI, and how our nice web server would now fork off our programs to generate the HTML.

I remember my first CGI programs were written in C, and Scheme. I quickly moved on though, and found the beauty, and craziness of Perl.

I spent quite some time with Perl, trying to get by without writing too much NSAPI and ISAPI code (oops, I guess that core dump hurts the entire server?).

I really enjoyed the community at that time. #perl was interesting (some of the time), and CPAN became the holy grail. As soon as you thought you needed something, someone had kindly put that functionality up into CPAN. I even have some of my own modules hanging out there, and helped with others.

Over a short time period, we had developed some fairly rich web modules. We didn’t have to work with $ENV{’SOME_CGI_ENVIRONMENT’}, or STDIN or the like. Our framework abstracted all of that for us, and gave us a simple model. We lauched at the folks who generated html via methods such as b("whee") and we stuck close to HTML itself, allowing our design teams to simply open the html files and see what their stuff looked like. We even had the notion of components, and special tags that you could create. <$mytag name=”…” /> was nice because the name of the tag was the key for the framework to dynamically discover that functionality. No config files, or interfaces, in the strict sense. The coupling was based on a name.

In retrospect, life was pretty simple for web development, a lot simpler than some of the frameworks we have today!

But, we moved from Perl. CGI was not the nicest for our high load servers. It was crazy to think that we would fork a process for every little request that came in, and that a Perl interpreter would start up, load the program, do the work and then die off.

We naturally moved to solutions such as mod_perl, and that helped. It was so new though that it was buggy and we had a lot of problems. Some of the problems had nothing to do with mod_perl itself, but due to laziness and side-effects.

When you work in an environment like CGI you can be a very bad man indeed. If you don’t close something correctly, or don’t play totally nice with resources, baaaah who cares? The server is going to kill me in 2 seconds anyway, so I will get my job done and have him kill me. In mod_perl world though, these programs start to live longer, and they get fat and oily.

Java: No more stinking processes!

Remember the beginning of Java (Oak!). We were building applets, and feeling the pain very early on.

Servlets were the big thing though. We ported our Perl based framework over, and were able to see significant performance improvements at the time. Some of the team loved the change, others hated the verboseness and static typing.

The nice threading model that Java gave us was huge though, even with the poor JVMs back then (Microsofts was by far the best remember!).

This is when we moved from the world of Perl to having Java start to take over. That isn’t to say that there wasn’t competition. In the waters we saw the lurkers of ColdFusion, ASP, and the beginning of the PHP revolution. Java came up with JSP to compete with these tag based approaches, but it was the advent of the rich MVC style frameworks that really spurred everyone on.

In my opinion Java is still in the hot-seat, especially in the corporate world.

Preparing for the server war

The troops are being gathered. Strategies are being worked out. We are currently getting ready for a new battle on the server side.

What’s happening?

  • Ruby on Rails: Whatever you think about Rails, it has lit a fire under the server side web development community. Many have jumped on the bandwagon, claiming real productivity improvements. Some of the PHP converts enjoy a richer language, which is still nice and dynamic, with a framework that enforces clean MVC techniques. Some of the Java community are frankly a little bored of Java, and enjoy the new challenge. They also love the freedom of the language, and the fact that they now have just ONE stack to worry about. Will the Rails buzz keep growing? Will it be the Perl of Web 2.0?
  • Java: Java isn’t going down without a fight. Some argue that the problem with web development in Java is that it has been too complicated and heavy for much usage. I have personally called for the need of a common stack for Java, and people have stepped up to the plate. On one side we have companies that will certify a set of technologies (JavaServer Faces + Spring + Hibernate). Then we get frameworks taking on simplicity themselves (WebWork now embedding Spring). Finally we have initiatives like JBoss Seam, which is trying to combine the component models of JavaServer Faces and the backend. Seam aims to give you the power of the Java tier, but also giving you a simple productive environment. So, Java frameworks are rising to the challenge of Rails, and we will soon see how much of the success of Rails is Ruby, and how much can be duplicated in other platforms.
  • PHP: We can’t discount PHP. A lot of “serious engineers” (read: anyone who isn’t a PHP developer thinks they are serious) poo poo the PHP world. Yet, by all accounts, there is a LOT of PHP development going on out there. PHP has the advantage of being something written JUST for the web. Take a look at how Wordpress came along (PHP based blogging software) and in no time at all there were thousands and thousands of plugins that you could simply drop into your Wordpress system. Literally, you drop in a file and you are done. There are numerous PHP frameworks that are aiming to mimic, and compete with Rails, so we can’t forget about these guys. The question with the PHP community is: will it grow more into the enterprise, or will it be for script-kiddies.
  • .NET: Never discount Microsoft. ASP.NET keeps getting more productive, and it is hard to compete with their end to end story, which includes fantastic tooling in their latest Visual Studio. And, we get Avalon and XAML along for the ride, as well as the futures of C# 3.0 which takes a lot of ideas from the dynamic languages and puts them into a static structure (such as: var foo = new Bar(); and the relational/xml integration)

It is going to be an interesting couple of years, as all of these platforms mature, and take eachother on, trying to get mindshare!

Client Side: JavaScript is cool again

But what about Ajax? The battle for the client side is going to be just as hot as on the server. And they will even intertwine with eachother.

Firstly we have the big debate of how far Ajax is going to go. Is it a one hit wonder? or will it become a standard part of our toolbox and even just be called dhtml again?

As an Ajaxian, I obviously have my thoughts on this matter. But there is a lot of competition inside and outside of Ajax:

  • Flash/PDF: Adobe/Macromedia are a definitely force to be reckoned with. Flash is almost ubiquitous, and PDF is used everywhere. Now the companies are combined, what do they have in store for us?
  • Avalon/WPF/E/XAML: Microsoft announced WPF/E, which is a subset of XAML that will be ported on various platforms and available in many browsers. This means that you can build your rich application in the .NET set of tools, and have it run in Safari on Mac OSX. Impressive. When are we actually going to see this in a form that we can deploy to the real world?
  • HTML: How much do we want to work in the open (ish) world of HTML. A large group of developers do not want to jump into any monopoly, and will therefore want to stick to a more open environment. But, another set will just want to use the best tool to add business value. What will the split be?

JavaScript will play a big role in this war. JavaScript 2.0 offers big improvements, that many people will cheer for. Also, the same people who poo-poo’d JavaScript in the past have come to realise that it really is a great language. It may not be what they are used too (it uses prototype-based OO vs. class-based OO), but it is powerful and robust. There are some features missing, and a big question around libraries. JSAN and others are trying to build a CPAN for JavaScript. We also worry about the black box of the JavaScript VM in the browsers, and cross-browser bugs are truly real painful. Fortunately, frameworks like Dojo and Prototype are trying to help us out on that front.

We are also seeing that we need to take JavaScript from the former:

“That is just crappy code that the web dood View-Source’s and pastes into the web pages”

to the future:

“JavaScript also needs to be engineered, and is a first class citizen”

Thus we finally see more unit testing of JavaScript code, and professional ways of creating modules and namespaces for our code. We also see great advantages with features like E4X where XML becomes a native type.

JavaScripts increased popularity, thanks to Ajax (and Flash/ActionScript) has also drawn it into the server side. Mozilla Rhino gives you a quality Java-based approach, so why not use a cool dynamic scripting language for certain tasks on the server side? You don’t have to use JavaScript for everything, but it has its place, and that place is growing.

The Battles Join

This is where the battles are joining. We have JavaScript bleeding across the layers, and we have the need for server-side frameworks to support the new Web. It isn’t enough to generate simple HTML and be done with it.

Today’s frameworks need to be able to help us build Ajaxian components, and help us write this applications quickly and cleanly.

There are various directions that frameworks are going in here.

  • JavaScript Code Gen: Why not give you a simple macro that splits out the ugly JavaScript that you would have to write?
  • JavaScript Framework Code Gen: Spitting out low-level JavaScript is too much work. Many frameworks are writing on top of a higher level JavaScript framework like Dojo or Prototype. Now the code-gen is less, and you get the benefits of the rich functionality, browser compatibility, and visual effects available from these frameworks.
  • Tools and Widgets: Should developers even care if a piece of their page is Ajax or not? Some frameworks give you drag and drop editors that let you setup widgets or components. Some happen to be ajaxian. Some are not. Who cares?
  • Markup based: A lot of frameworks are giving us markup based solutions. That is one of the strengths of Microsoft Atlas, not the fact that they added support for $() etc. Are we going to want to build using markup or via programatic APIs?

Conclusion

It is hard to predict the winners of the new battles, and the losers will not die off totally, but it is an exciting time to be watching web development. The dynamic languages of Ruby, JavaScript, and PHP are making a big run, and people are realising that they aren’t just cheesy scripting languages that can’t be used. It’s time to take them serious.

We are going to start really working out what makes sense for usability on the web with rich interfaces. And, at the same time we will get simpler and simpler backend tools to make the generation of rich web experiences easier and easier.

I am looking forward to seeing this battle!

Sep 23

WebWork 2.2: Coninuations, Spring, Dependencies, and Books

Java, Lightweight Containers, Tech, Web Frameworks 84 Comments »

A lot of great news has come out of the WebWork team. Having used WebWork on a lot of projects recently, I am a big fan, as it is simple and gets out of your damn way! :)

Some of the great news:

  • Continuations: RIFE and WebWork have partnered around continuations (at least). WebWork now contains an early version of RIFE/continuations, and provides experimental support for continuations. This is so we can get closer to SeaSide if we want. Take a look at an example action:
    public class Guess extends ActionSupport {
    int guess;
    
    public String execute() throws Exception {
    int answer = new Random().nextInt(100) + 1;
    int tries = 5;
    
    while (answer != guess && tries > 0) {
    pause(SUCCESS);
    
    if (guess > answer) {
    addFieldError("guess", "Too high!");
    } else if (guess < answer) {
    addFieldError("guess", "Too low!");
    }
    
    tries--;
    }
    
    if (answer == guess) {
    addActionMessage("You got it!");
    } else {
    addActionMessage("You ran out of tries, the answer was " + answer);
    }
    
    return SUCCESS;
    }
    
    public void setGuess(int guess) {
    this.guess = guess;
    }
    }
    
  • Spring IoC by default: WebWork is working with the Spring team too, and Spring is now the default IoC container
  • WebWork in Action: "Where is the WebWork book?". It's finally here
  • WebWork Dependencies: WebWork uses Ivy, and has a nice view of its dependencies

Amazing work guys.

Jul 04

Lightweight Development, NOT, Lightweight Container

Java, Lightweight Containers, Tech 5 Comments »

The term “lightweight container” has been en-vogue for a few years now (roughly since Pico/Spring came about). At first it kinda made sense, as they did seem tiny little containers compared to the big beasts WebLogic/WebSphere.

However, I think that the term is actually completely the wrong one. This thought came about as people have been saying:

“Spring is far from a lightweight container. Look at how much crap is available for you! Web/DAO/IoC/TX/AOP/RCP/JMX/Portal/WebFlow…. call that lightweight!!!”

It is true that Spring now has a lot of functionality available in its core, and a ton more hidden in the sandbox.

To me, the point is that Spring lets you apply lightweight development. I don’t need my container to be 10kb for enterprise development, and just be an IoC container. I actually WANT my enterprise container to be able to do the HEAVY lifting, allowing ‘lil ‘ole me to write in a lightweight, POJO based model.

So, I no longer think lightweight container. I think lightweight development.

I hope Spring keeps putting on the pounds as it makes more and more aspects of our development easier.

EJB 3 is a perfect example

EJB 3 is not a more lightweight container. They have just fixed the programming model, but the guts are exactly the same! People didn’t complain about the fact that EJB could grok TX automatically for us, they hated the programming model (Bean/Home/Remote interface etc etc etc).

I agree that EJB 3 is going in the correct direction, in that it is making our development simpler, and POJO based. We have to be careful with what we put in annotations though. I hate to see items like SQL hard coded in there, and ending up with a munge of the XML descriptors right in the bean.

Some items should be annotation driven. Others deserve to be external. Deployment is a big issue for large enterprises, and we need to have lightweight deployment too!

May 14

Spring Framework 1.2 Final Released

Java, Lightweight Containers, Tech 1 Comment »

The Spring Framework 1.2 Final has been released by the Spring team.

On this lucky Friday the 13th, we are pleased to announce that Spring 1.2 final has just been released.

(Thanks to Juergen for doing the packaging and his usual coding heroics). 

The major new features since 1.2 RC2 are:

  • TopLink support (for both TopLink 9.0.4 and 10.1.3)
  • JDO 2.0 support (tested against JPOX 1.1 beta 3)
  • Hibernate 3.0.3 support (aggressive release of Connections)

The overall major new features of Spring 1.2 are:

  • finer-grained distribution jar files
  • simplified XML bean definitions
  • JMX support
  • JDK 1.5 transaction annotation
  • support for WebLogic JTA extensions
  • JDBC RowSet support
  • JCA CCI support
  • JDO2 support
  • Hibernate3 support
  • TopLink support

Thanks to Oracle for donating the original TopLink support
prototype,  and in particular to Jim Clark from Oracle – for all his
help in getting the TopLink support into its final shape!

For details on new features, deprecations and bug fixes, please see the change log.

FYI, we have a 1.2.1 release scheduled for June, featuring minor
enhancements that did not make 1.2 final. See our JIRA road map for
details.

Kudos to the Spring team for a nice new final release :)

Time to test production code and get a migration plan…

Apr 20

Spring Modules 0.1

Java, Lightweight Containers, Tech No Comments »

It was cool to read from Rob that Spring Modules 0.1 has been released.

After a few weeks worth of effort in setting up the project and getting our initial codebase started, we have finally released Spring Modules 0.1.

This release includes:

  • Spring-style configuration for OSWorkflow
  • Support for JSR-94 rules engines
  • HiveMind integration
  • Commons Validator support migrated from Spring sandbox

You download the release from the home page.

As Spring has grown so fast, it needed a way to have modules, else how could it be called Lightweight? :)

0.1 has some useful stuff already, and I am sure there is a lot in the works to move over to that playpen.

Apr 08

Apache Beehive PageFlows vs. Spring WebFlow

Java, Lightweight Containers, Open Source, Tech, Web Frameworks 5 Comments »

Way back in time I worked on early releases of BEA’s Portal server. At the time they had their own MVC framework webflow, and it was a little painful to use (Remember the Rational ROSE tools for the Commerce product?).

However, that was many many years ago, and it has gotten better each release.

Now a lot of the same learning, is in place with Apache Beehive NetUI and PageFlows frameworks.

The Spring guys came out with a WebFlow component, which covers some of the same ground. How do they compare? At a high level their pro’s are:

Spring WebFlow:

WebFlow, although immature, does have an interesting goal in that it works on top of ANY web framework, and isn

Apr 07

Lingo: Indigo for Java without WS-*

Java, Lightweight Containers, Microsoft, Open Source, Tech 1 Comment »

Lingo is a new lightweight remoting / messaging library that smells a lot like Indigo in simple ways. The main difference is that the model isn’t baked in with WS-* XML blah.

It is cool that you have control over the messaging exchange patterns, and can do things like JMX over JMS very easily.

About Lingo

Lingo is a lightweight POJO based remoting and messaging library based on Spring’s Remoting which extends it to support JMS and support a wide range of message exchange patterns including both synchronous and asynchronous message exchange.

Current supported message exchange patterns include:

  • synchronous request-response (like RMI)
  • one way messaging (asynchronous invocation – like a JMS publish)
  • asynchronous consumption (like a JMS subscribe)
  • asynchronous request-reply (allowing the server side to asynchronously send one or more replies as the data becomes available).

You can think of Lingo as being conceptually similar to both Microsoft Indigo and JSR 181 in that it allows asynchrnous method execution, remoting and asynchronous messaging to be bound to existing POJOs (classes or interfaces) though it has no particular dependency on Web
Services infrastructure.

Lingo supports pluggable messaging bindings; the first binding is an efficient JMS implementation. Over time we’ll be adding other bindings to web services frameworks and other transports.

For more details of how Lingo works and what features it offers, see the Overview or try out the Example

Read more about the new: Lingo

Mar 31

IoC: One of those things you need to try, to get it

Lightweight Containers, Tech 7 Comments »

Everyone is chiming in on Cedric’s post claiming that he doesn’t get IoC.

I sometimes feel that the IoC crowd expects to explain IoC and have people say *a ha!*, and suddenly stand back with halo’s as they see the amazing benefits.

In reality, I always find IoC to be one of those ideas which seems simple, almost TOO simple, and hard to REALLY get.

The only way to get it in my opinion is to live it.

There are a lot of technologies like this. You can’t really understand what it does to YOU the programmer, until you do some work with it. E.g., using a real ORM, playing with Ruby/Lisp/Haskell, etc etc.

IoC, to me, gives me a way to help me write clean code. Nice units to test easily, forcing me to design to interfaces (which I tried to do before hand anyway, and which Cedric does (which is another reason why it doesn’t seem like a big deal sometimes).

I never want to see a lookup("foo"). As soon as I do I get the jibblies. What if foo isn’t there? What exceptions do I need to handle with foo?

So, for me, IoC is both a big deal, and a small deal. I don’t really think about it anymore. It is just part of the system, part of the pattern of writing code. It is used to help test, be agile, and all the cliches.

But, you won’t ‘get it’ until you just do some serious work using it… and then you won’t even think “oh I get it”, you will just be doing it.

Mar 29

Spring, EJB 3, and the future

Lightweight Containers 54 Comments »

I am often asked whether Spring will be a flash in the pan, and everyone will move to EJB 3. There are definitely a set of customers who want to do the standards thing… and I have already talked about a path for those folks.

Then I saw the following from Juergen, via Keith Donald, which shows the point of view of the Spring guys:

Spring and EJB3

On the surface it may seem that EJB 3.0 (in particular session beans) covers the same area as Spring’s Lightweight Container. However, when you look closer, you’ll notice some important differences with regards to the two, both in terms of focus and capabilities.

Dependency Injection

EJB3 provides dependency injection for JNDI objects. All referenced objects need to be managed by the application server in JNDI. This is only appropriate for coarse-grained facades, as there is no value in letting the application server manage every single internal object of your application. Essentially, EJB3’s dependency injection capabilities are targeted at making JNDI lookups more convenient, but do not go beyond that.

In contrast to the above, Spring is designed for managing fine-grained application objects in a local fashion, without making the application server aware of each and every object. You can link in objects from JNDI if you need to, but most of your application objects are not (nor should be) managed by the server. Furthermore, Spring supports prototypes, constructor injection, factory methods, simple property values, value placeholders (variable configuration properties sourceable from external locations), control over bean lifecycle (lazy-init, disposal, pooling), and bean autowiring.

The most important difference is that Spring can seamlessly manage application objects in any environment, while EJB3 just allows you to run them in an EJB container. In a test environment or standalone environment, the best you can do with EJB3 is instantiate the session beans yourself. With Spring, you’ll just select a different context implementation, typically sourced from the same XML bean definitions. This means you can reuse configuration metadata across environments with minimal hassel.

Other Capabilities

Beyond those basic IoC capabilities, Spring offers full support for proxy-based AOP with prebuilt and custom interceptors, while EJB3 offers its fixed set of interceptors (transaction, security). Furthermore, Spring’s declarative transactions are backed by various transaction strategies (DataSource/JDBC, Hibernate, JTA, JOTM), working outside of J2EE too. There’s also support for a wide variety of data access strategies (JDO, OJB, JDBC, all using a consistent programming model, while EJB3 just integrates a single strategy). If you haven’t guessed by now, Spring’s mantra is, “it’s all about choice”.

We’ve not even touched Spring’s web support yet, which range from basic web application context support to its own web MVC and web flow framework and prebuilt Struts/JSF integrations, all able to seamlessly reference middle tier beans. There’s also support for lightweight remoting with various strategies (Hessian, HTTP Invoker, Burlap, JAX-RPC, JMX) using a common service export facility, rather than the (unknown?) set of protocols that a particular EJB server implementation may offer.

Spring in an EJB3 Scenario

In many respects, Spring and EJB 3.0 complement each other more than they compete. Like it currently does for EJB 2.x, Spring will be able to link in EJB3 session beans seamlessly (local or remote), and will provide internal contexts for EJB3 session and message-driven bean implementations (holding a Spring bean factory within an EJB).

In such an EJB3 scenario, Spring manages the application objects in the web tier (no matter which web MVC framework is being used), accessing coarse-grainded EJB facades when necessary, and potentially also finer-grained objects behind those facades (for example, business logic strategies and DAOs, using JDBC, JDO, Hibernate, etc). Spring still acts as the glue for the entire application, just now with EJB3 session beans thrown into the mix.

Beyond EJB3 session beans, Spring will also support the new persistence API defined by JSR-220 (formerly known as EJB3 entity beans), as a further O/R mapping strategy, in addition to the current support for Hibernate, JDO, OJB, and iBATIS SQL Maps. Note: this will be completely
independent from the rest of EJB3–you could easily manage your entire middle tier with Spring, using a JSR-220 persistence implementation in standalone.

EJB3 in a Spring Scenario

I hope the above answers why it still adds value to use Spring in an EJB3 scenario. Of course, we can also turn the question around: What value is added by EJB3 session beans to a Spring scenario? (JSR-220 persistence is a different matter: It’s an alternative to Hibernate and JDO, not to Spring.)

In principle, Spring covers all capabilities of EJB3 session beans today, offering more flexible and more sophisticated management and deployment options. The main benefit with modelling components as EJBs is that you’re able to export remote services through your J2EE server (to support load balancing and failover).

For purely local needs, there appears no compelling reason to choose EJB3 session beans over Spring-managed POJOs, except for one specific
scenario: You might want to deploy some of your components in a separate class loader within an EAR, making them accessible to multiple web applications. In such a case, using local EJBs as facades makes sense, possibly with fine-grained networks of Spring-managed application objects behind them.

Juergen Hoeller, co-lead, The Spring Framework