Semergence

The final afternoon talk on the final day of The Spring Experience is Pragmatic AOP with Spring and AspectJ.

Aspects are modular, enhancing the value of the software overall. Aspects lead to DRY SOCs (Don’t Repeat Yourself, Separation of Concerns).

Join points are well defined points in the execution of the program.
Pointcuts are expressions that match join points.
Advice is action to take at those join points. Advice is not explicitly called, unlike methods.

Typical applications are Spring managed for data access, services, web controllers, transactions, etc. Up to now, the Domain Model has not been managed by Spring.

Spring AOP is a good fit for Spring managed beans, execution based join points, or coarser-grained service application. Or any time where the aspect is slower than the impact of the proxy itself (ie, transactions).

In Domain Driven Design, another separation of concern (SOC) is the Technical Concerns (transactions, auditing, etc) from the Business Concerns (the Ubiquitous Language, language of the business domain experts).

AspectJ is perfect for integration with the Domain Model, in contrast to Spring AOP which is good for advising the service layer.

What makes a good aspect? Does the aspect reduce coupling?

Aleksander Seovic, Mark Pollak, and Rob Harrop are presenting an Introduction to Spring.NET.

So the first question is Why Spring.NET? Simply, the IoC container transends platforms. Also, a lack of similar toolsets and libraries on the .NET platform required a Spring.NET.

However, it’s not a direct port, as the two environments have quite different practices and conventions.

One benefit to the Spring Community is a bigger core development team, and a good cross-pollination of ideas. For instance, the new XML Namespaces and XSD configurations originally came from Spring.NET.

A similarity between Spring.JAVA and Spring.NET is the transaction handling. AOP exists in Spring.NET, but implemented differently. One difficulty with aspects in .NET is methods are by default marked as final.

You’ll find there are naming differences between the two environments. Object vs bean, type vs class, dictionary vs map. In .NET all exceptions are unchecked. Configuration is more formal in .NET, something that is ad hoc in Java (ie, just putting some file into META-INF).

With Spring.Web, you can now Dependency Inject your ASP.NET pages.

Day Three (Full Day Two) here at The Spring Experience, and the morning session has Jurgen Holler talking about Spring’s support for JMS and JCA. He knows his stuff. We’re going over the standard synchronous JmsTemplate, useful when you’re not running an asynchronous JMS listener.

Spring 2.0 has full support for asynchronous message receiving with POJOs. This is the elusive Message Driven POJO, important when Message Driven Beans (MDBs) aren’t available.

An important note about the JmsTemplate is that it fetches a Connection for every request. In a managed environment, this is OK, because the container will pool Connections. However, in a non-managed environment, be sure that the ConnectionFactory is pooling connections.

For asynchronous message handling, you can either use MessageListener and manually register it with the Session, or use J2EE’s Message Driven Beans. In either case, you are using a framework interface (MessageListener) which is not POJO compliant. Also, typically if you want XA and asynchronous message reception, you need to use MDBs.

Enter Spring 2.0’s new message listener container. You have the option of implementing MessageListener, or the Spring specific SessionAwareMessageListener. As it sounds, you get a onMessage(Message, Session) method. This is useful for sending reply messages, and you’re able to thrown JMSException.

The Spring provided message container is the DefaultMessageListenerContainer. It supports XA message reception, works with all JMS providers, simply uses MessageListener and MessageConsumer facilities. However, it does create one thread per consumer, which is forbidden by the J2EE contract. However, you may still do this and usually doesn’t harm much.

Note that XA transaction handling provided by the container starts the transaction with message reception. That is, the message reception is within a transaction.

SimpleMessageListenerContainer is an alternative container, but does not support XA message reception and does not create custom threads. This is useful outside of a container.

ServerSessionMessageListenerContainer uses JMS’s ServerSessionPool, which is a SPI into the JMS Server. However, not very useful in J2EE containers, as the spec forbids the use of ServerSessionPool. Also does not use XA transactions.

Much of this is possible through the new TaskExecutor abstraction, for creation of custom threads. Three different implementations including a ConcurrentTaskExecutor which uses JDK1.5’s ThreadPoolExecutor or WorkManagerTaskExecutor which is for modern J2EE containers like BEA WebLogic 9 or IBM WebSphere 6. This executor uses the CommonJ WorkManager abstraction, allowing J2EE applications to formally and correctly use threads from within the container (forbidden by the spec). However, CommonJ is not a JSR, but is supported by BEA and IBM.

DefaultMessageListenerContainer is the recommended container, useful for most needs.

The first talk today from The Spring Experience was Justin Gehtland’s Spring, Mule, and the ESB. Justin thought it was going to be attended by only a few people, but instead the room was quite full.

His talk covered what an ESB is (generally speaking, doing a good job not to do too much arm waving), what Mule is (short answer: an ESB container), and how Spring can be used for tasks like Mule configuration and Mule components.

Justin’s style is quite good, and I can recommend you check him out if you happen to be at a conference with him. Or, just corner him and yell, “Hey, it’s Justin Gehtland!” He loves that.

I’ve used Mule once, evaluating it for a project. We needed to shuffle files around, uploaded to us via FTP every night. At that time, Mule’s support for file based messages was limited, so we didn’t end up using the product. I think it was mainly because Mule didn’t natively support the universal workaround for file dumps (place a zero-length “I’m Done!” file to indicate file upload is complete).

However, if your system is message based (where message can be email, web services, TCP, or JMS) then take a look at Mule. It provides the container concept to your messaging architecture. It’s actively developed and very flexible.

Attended the Transparently Clustering Spring talk, with more information at The Server Side press release.

The crowd quickly steared the talk to a technical overview of the product, and it was quite interesting once we got them to stop hand waving. The product is not FOSS, but still pretty cheap (mentioned about $2k per node).

The product, named Terracotta Distributed Shared Objects, provides essentially a networked shared heap. This is not a standard object caching thing like Coherence, this product maintains object identity.

We’re here at The Spring Experience keynote, given by Rod Johnson. It’s Wednesday evening, and dinner has finished up.  The approx. count for attendance is 275, not a bad number.

His talk is titled Spring Today and Tomorrow.  Spring is “the most powerful technology for enabling POJO-based application development.”  The majority of Interface 21’s clients are in the backing sector.

The framework is released in Feb 03 as open source, released as Spring 1.0M1 in Aug 03, and finally 1.0 Mar 04.  Spring 1.1 arrives in Sept 04, 1.2 in May 05, and Spring 2.0 M1 is released at The Spring Experience.

New features of Spring 2.0 includes:

• Bean Scoping
• CommonJ timer manager
• Portlet MVC
• Message-driven POJOs
• Configuration simplification (XML or Java code)
• SimpleJdbcTemplate – Java 5 features

Still committed to Java 1.3.

Coming up, what will get better?

• Configuration can become simplified – Use XML namespaces, XML schema to reduce code, use custom domain specific tags, and better IDE integration.
• Closer integration of Spring AOP and AspectJ.  Spring AOP gains AspectJ pointcut expression language, also gains the @AspectJ syntax.  AspectJ gains Spring DI, for instance to DI domain objects.

Spring serves two communities: conservative users and early adopters.