It was quite a week of learning with the folks from Spring Framework in the SpringOne Conference in Chicago.
Not only I had the opportunity to hear Spring explained from the code committers but I managed to discuss some common architectural, managerial and leadership issues with other attendees.
The amount of work Spring helps to solve could be enough for four weeks of conference so there were mainly 4 slices (or tracks) of very related conferences from which you had to pick just one. Here are some comments about those that I attended.
Javascript application engineering
It is clear javascript is now stronger that ever. It was a nice look into how to do Object Oriented Programming with Javascript, Inheritance through prototypes (Object.create(Object.prototype)), closures and more. Between others websites like Javascript weekly and hacker news were recommended to be followed up.
Spring Integration. Practical Tips and tricks
The Spring Integration project is an attempt to implement the patterns described in the book Enterprise Integration Patterns Book by Gregor Hohpe and Bobby Wolf
It was a discussion about Consumers, Producers and the Publish/Subscribe pattern using AMQP channels and comparing them with JMS channels. Of course SOAP, REST and others are supported. Channel redundancy was presented Rabitt MQ and JSM. The project reminds me of ESB and indeed there was a mention to it. Basically Spring Integration is a different approach than ESB because there is no server needed but just patterns applied.
Messaging
Messaging was presented through the Rabbit MQ which is the reference implementation of the Advanced Messaging Queue Protocol (AMQP). It was even proposed to start sending messages between Controllers and Services to prepare the application to scale in the future. I have to say I won't buy into that even though for sure I would consider using it to implement future distributed needs in my projects. Messaging was presented as a way around problems inherent to the use of shared class loaders (OSGI). In reality that is what any distributed technique does after all, being more than anything a consequence of the paradigm in use.
Neo4J
This is a graph database and the presentation was useful especially to eliminate any of the ongoing discussions about what is the best database out there in the NoSQL domain. It is clear they all address different problems while of course there is more than one choice within each possible domain. Basically there is a trade between size and complexity and in that order we have different options like key-value, bigtable, document, graph.
Spring Insight Plugin Development
This is a project with a mission that sounds familiar: Inspect how the application is behaving performance wise. Classes are annotated with @InsightOperation and @InsightEndPoint to allow performance inspection: Basically how long the method gets to execute. In other words where the time is spent in the application. While this could be definitely useful in many scenarios we have tools doing this already so it looked to me like an effort to build a lightweight profiler focused on vFabric.
Spring Integration. Implementing Scalable Architectures with Spring Integration
A simple implementation based on a simple relational database locked row was presented to provide a messaging cluster implementation.
Spring Batch
In a glance this is a project to manipulate data. We learned how Spring Batch works while defining and instantiating jobs (Job and Job Instance) that basically act on data. I will not start a war about if
spring is better or worst that etl for this task. It is just another way of doing the same and depending on your architecture and team one will be favored over the other. I tend to separate concerns as much as possible and I think data is better processed and tackle by data centric developers and existing tools. In my experience most of people dealing with Spring actually love to implement business rules that are not necessarily related to data intensive processing. But again this discussion should end here, there is not correct way just different ways.
Deliver Performance and scalability with ehcache and spring
JSR107 will standardize caching while some of us still use some
caching api from Google code to cache data at method level. However terracotta ehCache and the new standard add more flexibility to caching. For simple caching you can use the Google code API but for more complicated situations you will use this approach which involves @Cacheable and @CacheEvict annotations. When the source code is not available @Cacheable can be used from XML which is great you will agree. AOP helps here to cache certain methods. Different providers like terracotta backed open source Ehcache offer different possibilities which go beyond the basis of the default ConcurrentMap implementation. Automatic Resource Control now in beta will allow ehacahe to use cache sizing in terms of bytes or percentage besides the existing object count. Then of course you can even go for enterprise class monitoring with "terracotta Developer Console".
Eventing Data with RabbitMQ and Riak
Riak was discussed as the unique NoSQL database that would allow hooking into the data insertion. This is of advantage to create a trigger for RabitMQ when new data gets stored. A very cool example was presented where WebSocket was used to notify the client directly from the server. Again the CAP theorem was discussed: You must pick one from Consistency, Availability and Performance triangle and that would ultimately drive your decision towards one database or another.
Where did my architecture go
It was disscused how to control the gap between architecture and codebase. Here you have code analysis with JDepend and Sonar, SonarGraph (formerly SonarJ). Suggestions were made about the usage of ServiceLoader or OSGI for externalizing class creation.
Tailoring Spring for Custom Usage
As we all know Spring is about DI, IOP and Enterprise Service Abstractions (libraries). This lecture went through each of the components giving real case utilization of them. We saw @Configuration and @Bean to provide configuration from Java code instead of XML, @Value to allow the injection of a system property as a string member of a class, Spring scopes to be used for example to eliminate the need to pass custom context objects from method to method (A technique that I still use in my projects for maintaining ControllerContext), even though Singleton and Prototype are the most common scopes there are several others like Request and Session, @Profile annotation to define production or development. The Spring expression language in general was introduced.
Improving Java with Groovy
There were several trcks of Groovy and Grails. I attended just this one from the latest slice because there was nothing for Spring Java available and even though it was basic stuff we saw examples that did work from an excellent demo showing how to use both Java and Groovy in your project. It was basically a practical presentation of the ideas behind the book "Making Java Groovy". Heavy use of closures showed how the code got smaller while avoiding Interfaces and Inner Classes.
No comments:
Post a Comment