SpringOne 2008 Day 3
December 4, 2008 3 Comments
RESTful Web Applications with Spring 3.0 – Arjen Poutsma
The “highlight” of the presentation was Arjen’s bright green hair, no really. Rumor has it that he lost a bet? The hall was filled to capacity with people sitting on the sidelines. Some of my take-aways:
- there is no “right way” way to design REST-ful URL-s, some are better than others, subjective. As someone who has used the Flickr API as a reference, that was good for me to hear. REST zealots would argue that the Flickr API is not a good example of “true” RESTful style, whatever that means.
- but using hierarchical URL-s and avoiding query string parameters or method “verbs” in the URL is recommended
- one of the ways you can keep things simple is use the HTTP response codes to determine success / failure of an operation
- use ETags of course, gives you caching advantages, Spring 3.0 can automatically generate the ETag (using an MD5 hash compare)
- expect “representation” support (just like MVC views) for Atom / RSS, JSON etc. XML marshalling support is already there in Spring Web Services
- annotation driven URI templates look quite nice and elegant, can’t wait to try these out
Terracotta – Real Apps, Real Frameworks, Real Use Cases – Ari Zilka (CTO & Founder)
Terracotta sounds too good to be true, I keep wondering what is the catch!? Colin Sampaleanu from SpringSource was also on stage for the first few minutes with a quick intro and comments on how SpringSource and Terracotta are working together to do really big scaling for a client in production. A Terracotta PoC would be high on my to do list when I get back to my workplace.
- they have an oss reference app you can download and try called Examinator on the Spring WebFlow / JPA (Hibernate) stack
- no need for SAN / NAS etc, commodity hardware with local IDE / SCSI etc will do
- Terracotta does all kinds of magic with the JVM behind the scenes. Because it works at the JVM level, you hardly have to make any assumptions when you code, for example your objects don’t even need to be Serializable
- need a cluster wide singleton? no problem
- lots and lots of optimizations like using only deltas, lazy loading, minimizing disk flushes by consolidating fine-grained operations, use local memory for reads as far as possible etc
- use sticky sessions in general as far as possible. and if you use Terracotta with sticky sessions, because of the above mentioned optimizations – Terracotta “will fly”
- I was quite fascinated by Ari’s detailed answer to a question on failover – heartbeating between nodes, nodes hold “elections” to decide who becomes master / passive when new nodes appear or disappear…
- some stats: client they and SpringSource are working with on can hit 20,000 TPS on 16 DELL blades with 5ms response time. Now they are on the way to hitting 50K TPS with the same infrastructure.
- demo of the Terracotta admin console was impressive, he ran a JMeter script. The console can even have you drill down to a thread dump on a node you choose
- made an interesting comment about a client using Terracotta for messaging “across political boundaries”, you can do things you normally expect messaging / JMS to make possible
- in case native stuff is involved, you would have to have a proper design to keep all the ‘state’ you need within the Java boundary as far as possible. mentioned a case where they could cluster even comet sockets this way
Spring and Java EE 6 – Jürgen Höller
This session was quite useful for me because I have not been really bothered about the evolution of Java EE much (true Spring fan :P) but here was a great summary from someone working hard to keep Spring complementing Java EE as far as possible.
- Java EE profiles mean that container vendors don’t need to support all the legacy stuff like EJB 2.0 anymore. I can very well see Spring “tc” server being one of the first containers to be certified when the spec goes final ;)
- Comet support will be in the Servlet 3.0 spec, I didn’t really know that
- Again and again the message is that the upcoming spec overlaps with existing Spring functionality – e.g. JSF 2.0 @ManagedBean, @ManagedProperty is nothing but Spring @Component, @Value
- Another example, web beans binding annotations are the same thing as Spring @Qualifier
- Jürgen’s opinion is that the Web Beans spec is changing a lot, making a lot of “sharp turns”. Feels that there is a lack of consensus on some decisions like sub-grouping the many annotations into logical packages. Pretty much delayed.
- Says that Spring 2.5 provides a lot of Web Beans functionality already and spring 3.0 closes the gap
- Another comment he made was that the committee has a tough job – there is already a well established component model which is EJB3. And now Web Beans is supposed to do *only* things that EJB cannot do.
- So is EJB 3.1 going to end up as a great complement to Web Beans? Jürgen doesn’t appear to think so.
- The fact that a “singleton session bean” is planned in the spec was news to me. You will be able to even annotate methods as single threaded, async etc
- Whatever specs are final / close would be included in Spring 3.0, for example JPA 2.0 quite likely. But you really can’t predict everything at this point
At the end of the day I caught parts of Adrian Colyer’s keynote. One notable announcement was Spring will support Flex and SpringSource would be partnering with Adobe. Adrian proceeded to do a Grails live-coding demo on stage working with Spring Integration as well, looked like the audience was lapping it all up, I had to leave at this point.
Update: video of the skit by the SpringSource folks before Adrian’s keynote is available here: