~pperalta

The Quick Start with Acegi talk by Ben Alex was a beginner’s guide to Acegi. The focus was on the limitations of container managed security and how Acegi addresses them, including:

• Not portable at WAR level. Each container has vastly different methods of implementing security (Tomcat realms, JBoss LoginModules, etc.)
• Only web requests at the URL level can be secured; Acegi allows method level authorization
• No support for nice features such as “remember me”

One of the issues that I had with Acegi when I first started using it (version 0.7) was how verbose the configuration was. This is supposed to have improved recently, and it is supposed to be even better when it is integrated with Spring 2.0. I’m looking forward to the Acegi 1.0 release.

The remoting talk covered all sorts of remoting technology, such as RMI, IIOP, Hessian, Burlap, SOAP, and Spring’s HTTPInvoker. In general, the proxy based solutions that Spring provides for remoting makes it easy to choose the right remoting technology for your project.

Speaking of remoting, I had an interesting conversation with Mark Pollack regarding JMS remoting. A concept that he has worked on is to use JMS for interoperability with .NET and Java. His project maps object properties to nested map messages in JMS. Using a tool to convert Java to .NET, he generates the .NET version of the data objects and uses proxies to translate between the JMS messages and objects. That sounds like an interesting alternative to IIOP for interoperability.

The dinner time keynote by Rod Johnson announced BEA realtime server which is a new product by BEA targeted to customers that require very high performance for server side processing. This is meant for applications that have not moved off of C++ yet because GC pause time is not an option. The core of this BEA product is Spring, which is quite the validation of the performance that Spring can provide.

A partnership with Geronimo was also announced. I noticed that quite a few demos during the conference were using Geronimo. Rod also mentioned the TopLink DAO support that was donated by Oracle. A major theme with Spring is that it does not try to lock you into a specific vendor; in fact they strive to be as vendor neutral as possible in order to have wide acceptance.

Next Adrian Coyer gave a talk on AOP and its role in making Java simpler yet more powerful. You can throw a lot of money at software, but no amount of money will ensure high quality. The best chance at success is simplicity, but real world software is complex. Using the combination of dependency injection, aspects, and annotations/metadata, we can make software in a simple and modular way, yet allow for complex interactions at the same time. It is for this reason that aspects and AOP will be the next paradigm shift to follow after OOP. As Rod says, knowing and using AOP is a competitive advantage today, tomorrow it will be a competitive necessity.

This morning was Advanced Spring MVC with Rob Harrop, which consisted of a deep dive of Spring MVC form processing, controller testing, i18n, exception handling, and using multiple view technologies in the same project. The slides are very comprehensive and do a good job describing all of these features.

Today’s coverage of the lunchtime expert panel has been brought to you by Jim Moore.

This morning I went to an Ajax talk that focused on DWR (direct web remoting) which exposes Java objects via JavaScript. The Spring integration provides direct access to beans in the web application context. Right now this is implemented as a servlet that is included with the web application, but they will soon provide tighter integration with Spring by providing a Spring MVC controller instead of a servlet. Overall it looks like very cool technology that requires minimal JavaScript to be coded inside of event handlers. I look forward to trying it out.

Afterwards I attended a session on Spring .NET. The motivation was to provide dependency injection for the .NET framework, especially for those spoiled by the DI provided by Spring on Java. Note that this is not just a code conversion port; much care is taken to develop this framework using .NET conventions and style. Non invasive DI frameworks are useful under any language or platform, and .NET is no exception.

Java developers familiar with Spring already know about the benefits of DI and are therefore drawn to Spring.NET, but most .NET developers that encounter Spring.NET do so because they are searching for a framework to ease .NET web development. After trying out the many features provided by Spring.NET such as the bi-directional data binding and the improved validation and i18n support, they get hooked on the DI container just like the rest of us!

They also provided a demo where a calculator service was consumed with a .NET client. The service was deployed using .NET remoting, RMI/IIOP, and WebLogic. That would be useful for creating Windows desktop clients that use J2EE as a middle tier.

The roadmap for Spring.NET includes a framework for WinForms clients, ADO.NET data access layer (like Spring JDBC), integrations with NHibernate and IBatis.NET, Spring WebFlow support, multiple view types for web applications, and more.

Jurgen Hoeller gave a talk about 10 Cool Spring Features You Might Not Be Aware Of. I was somewhat familiar with most of them, especially the native JDBC connection and CLOB functionality, which I’ll talk about more during this session. There were two features that I was not aware of that look interesting for our application.

The first is lazy JDBC connections. This is a feature where a DataSource is wrapped in a DataSource implementation that returns a proxy for getConnection() instead of a real connection. This proxy will only get a real connection when it is needed. The use case for this is declarative transactions (using local transactions, not JTA) where the data that is being requested by the caller is cached. The declarative transaction manager gets a connection, turns off auto commit (although I think this depends on the environment), and starts the transaction. When the service method is done, the connection is committed. However, if the data being returned by the service is in cache, then we have made up to 3 calls to the database that were not needed. In high volume applications this can add up to a lot of overhead, especially depending on the level of isolation configured for the database connection.

The other interesting feature is the Task Executor. This is meant for launching functionality that should be executed asynchronously. They provide several implementations, including ones based on java.util.Timer, the JDK 1.5 concurrent library, and CommonJ WorkManager for WAS and WebLogic. The latter would be required if the application uses EJBs since EJBs can’t launch new threads (or at least they’re not supposed to). If needed, implementations could be provided for other EJB containers such as JBoss, but I suspect that most Spring applications are being deployed as WARs anyway which makes it a moot point.

After the talk I spoke to Jurgen about providing a JMS Invoker for JMS based remoting. I submitted an implementation before realizing that an implementation already existed in the sandbox. However, my solution performs serialization manually and uses BytesMessage instead of ObjectMessage because Tibco has issues serializing primitives. I would be interested in seeing a JMS remoting solution in Spring, and the JIRA issue was marked for Spring 1.3 (which is now Spring 2.0). I do know about the existence of Lingo so I suppose it is possible that this would be the JMS remoting solution instead of rolling it into the main project.

Speaking of Jurgen, he gave the keynote speech after dinner. The topic was “Spring’s Nature,” where he was talking about the characteristics and philosophy of Spring. Some highlights:

• Spring is very modular, and separation of components is taken very seriously
• It covers many different areas, but the design is very consistent
• Some subsystems are so independent that they effectively are libraries
• Implementation classes are considered part of the public API
• Many hooks are provided for easy customization

Spring is analogous to an ice floe: has broad coverage but is very shallow. Spring provides integration hooks for many things, but it does not provide anything that already has a good solution (such as ORM). J2EE is more like an iceberg: only a part of it is visible, but there is a lot that is hidden from view.

After lunch we had the expert panel taking questions from attendees. The first question was about domain models and the role that they play in application architecture. In particular, the term Anemic Domain Model was tossed around. To paraphrase Martin Fowler, this happens when a domain model exists but does not contain any behavior; instead the behavior is defined in the service layer. Using the service layer instead of the domain layer for behavior is more procedural than OO. The hard core OO crowd is not too thrilled about this, especially for complicated apps that could benefit from a strong OO model. However there are some real world constraints that make this architecture difficult. One roadblock is that it is difficult to do dependency injection on domain objects, especially when they are created with an ORM tool or with the new operator. Another example is with Apache digester: we have an application that creates domain objects based on an XML stream, and these objects have behaviors that require DAO access. The only real way to do this right now with Spring is to have a static reference to the bean factory. (Yes, this is a really ugly hack) However, with the improved AspectJ integration that is going into Spring 2.0, performing DI on domain objects will be much easier. This will allow domain objects access to the DAO or services layer, which should make it easier to associate behavior with them.

Another discussion was started about using annotations and whether frameworks that rely on them should be considered “light weight” since the annotations tie them directly to the framework. This question got Rod on his soapbox about why using annotations for configuration are not such a good idea. This reminded me of a posting by Craig Wells on this topic a few days ago. The argument is that annotations are meant for class level configuration, not object based configuration. If configuration is set up in the Java class file, then it becomes very difficult to configure individual instances of that class.

I have not had the chance to move our middle tier to Java 5 yet, so I do not have much experience with annotations. However, I do have to say that I tend to agree with this idea. In our project, we have an entire layer of mock DAOs that we swap during testing to test our service layer. Since these configurations are defined externally via XML, we’re able to swap out DAO implementations for our services without affecting the services at all. I suspect this would be more difficult with annotations since it would require modifying the Java source itself instead of just configuring the application context to load one set of DAOs for testing and another for deployment.

Of course this would not be a Java conference in 2005 if no mention of Ruby on Rails is made. The Spring team does admire the concept of convention over configuration although it is more difficult with a statically typed language like Java. However, the developers are very interested in dynamic language support in Spring, and they are also looking to simplify the MVC configuration for Spring 2.0.

The concept of setting up a foundation for ownership of Spring (ala Apache) was also mentioned to be in the works. This should be set up by Q1 next year.