Spring has been one of the most exciting frameworks to emerge in the past few years. With Spring you can decouple your application's objects, enrich them with AOP, and apply transactional boundaries and security to them declaratively. It simplifies data access, remoting, web services, and JMS. It comes with its own web framework. And, even though Spring eliminates much of the need for EJBs, it will still integrate nicely with any EJBs you may have lying around. What's not to love?

Everyone's favorite Java framework continues to improve, with significant enhancements in Spring 2.5 and many more coming in Spring 3.0. Maybe you've already seen or read about Spring and perhaps you've even developed applications using Spring. But have you seen the latest that Spring has to offer.

In this example-driven presentation, I'll lead a guided tour through the key features of Spring, with an emphasis on the Spring's core facilities of Dependency Injection and Aspect-Oriented Programming. Whether you're a Spring newbie or a seasoned Spring developer, there'll be something new for nearly everyone.

The biggest complaint about Spring is the vast amount of XML required to configure an application. In this presentation, I'll show you ways to reduce or even eliminate much of the XML required to configure Spring.

A typical Spring configuration file will contain dozens (or even hundreds) of lines of XML. Because of all of the XML clutter, some have started looking for alternatives to Spring that don't require so much configuration, even if it means forfeiting all of the benefits afforded by Spring.

But before you throw the baby out with the bathwater, you should know that there are several ways to simplify Spring configuration so that it isn't so XML-heavy.

In this presentation, I'll show you ways to cut back on Spring configuration while still achieving the same results. I'll discuss a few XML reducing ideas, such as custom configuration namespaces, and I'll also show you some XML-free options such as using Java 5 annotations and scripting languages to configure Spring.

Many web-service platforms make web-services easy by simply SOAP-ifying an object's interface. That's certainly a quick way to get started with web-services, but what happens when the object's interface changes?

The contract between a web-service and its clients is often determined in a "contract-last" approach. That is, the service is designed and developed with little or no thought put into how a client will interact with it. Then WSDL is generated on-the-fly when the object is deployed. As a result, the contract is coupled to the service implementation's interface.

The promise of SOA is a network of loosely-coupled services that can be assembled into larger applications. But if the contract is coupled to the service implementation's interface, then the client is also indirectly coupled to that same interface. When the service implementation changes, the client must also change.

Thus we have the classic versioning issue associated with web-services. When a service's contract changes, you can't realistically expect all of its clients to change right away.

One solution is to never change the service--design it up-front with everything it will ever need and never change it again. But this isn't very practical, as there's no way to predict what impact future requirements will have on the service. Yet another approach is to deploy multiple versions of the service. But this adds to the maintenance costs by having to juggle multiple versions.

Another option that is gaining a lot of attention lately is the notion of contract-first web-services. The contract-first approach is message-centric. Instead of treating web-services as "RPC with angle-brackets", contract-first treats web-services as message receivers. In doing so, a web-service can be written in such a way as to decouple its from contract from its implementation.

In this session, we'll take a look at Spring-WS, a Spring-based web-service framework for building contract-first web-services.

Learn how to clean up your build process with Maven 2.

Writing code is fun. But writing build code is...well...not so much fun.

How many times have you written the exact same "clean" target in Ant? How about "compile"? Or "war"? Let's face it: Virtually every Ant build.xml file ever written is pretty much the same as every other Ant build.xml file.

If writing build files is no fun, and if they're all clones of each other, then why do it?

In this session, I'll show you how to use Maven 2 to manage your build. Unlike Ant, Maven already knows how to compile, how to clean, and how to produce WAR files. You won't ever need to write (or cut-n-paste) that same build.xml file again.