Well, today was the final day of this year’s [tag]TSSJS[/tag]. It’s been a really busy few days, I have been looking forward to some downtime but first I need to get this final blog entry completed!
There were two sessions today that really caught my interest:
- Cutting Edge Productivity with [tag]RIFE[/tag] – Geert Bevin of Uwyn and Terracotta
- A Fast Hop into [tag]Real Object Oriented[/tag] ([tag]ROO[/tag]) – Ben Alex of Interface 21
There was some common ground between these two sessions and in fact the more that I look at RIFE, it looks to me like a mini-Spring Framework. I don’t intend any disrespect to RIFE here, in fact, just the opposite! It appears that Geert and his team have really focused on what problems needed to be solved in developing web applications. It just happens that some of these problems exist in whatever development layer, web/service/data, you generally find yourself coding in.
If you look at what some of what RIFE has to offer:
- Web Application Engine
- IoC Support
- Authentication Framework
- JDBC Abstraction Layer
- Database Query Builder
- Persistence Layer
Sound familiar? Geert did go out his way to mention that RIFE is not an ORM solution so at least it would not be considered as a replacement for something like Hibernate.
One very neat feature of RIFE is the notion of continuations. [tag]Continuations[/tag] seem to allow a web application to act somewhat like a computer game i.e. in a game you can save game, in a web application you can save state. At any point you can return to the point of the saved state; useful, you would think, in managing state through complex web flow.
I believe, and I am open to contradiction here, that RIFE stores the various states in memory. So if, for one user session, the application passes through multiple save state points, then multiple user states, for the one session will be stored in memory. I wonder what the memory implications of this model would be in a real world application with a large number of users?
ROO (Real Object Oriented), presented by Ben Alex, covered a topic that has direct relevance in the work that we (DSI) are doing today. We embraced DDD ([tag]Domain Driven Development[/tag]) over 12 months ago, and have successfully implemented DDD in a number of projects. In saying that, we knew that our approach required some fine tuning, and only three weeks ago, I met with a couple of leads from one of our larger projects using DDD, and we spoke about reintroducing Data Transfer Objects and some kind of intermediary assembler layer into the architecture.
Ben’s presentation may turn out to be very timely. ROO proposes that we layer our software according to strict OO principles i.e. that an object should have clearly defined state and behaviour and that this behaviour should not extend beyond the limits of the objects boundaries. A good example of this is a domain object that is Hibernate enabled. Today, this object resides in the persistence layer, but it is being serialized and passed over the network, via a set of services, to calling clients. Ben is correct in saying that this type of object, which should reside in the Domain Model layer, is specialized in conversing with whatever persistence mechanism you are using. Similarly a specialized DTO should be created for the purposes of transmitting the data across the wire with clear architectural boundaries existing between the Middle-Tier Exporting layer and the Domain Model layer.
I don’t think Ben has necessarily invented any new ideas here, but what he has done successfully is taken a bunch of tried and trusted design patterns and built a framework around them that would allow you to create a set of services in a reliable and consistent manner. Yes, it uses code generation technology, but it does so in a manner that it works around some of the bug-bears of existing frameworks that use code generation e.g. version control compatibility and customization flexibility.
This is definitely something that we will be keeping an eye on. Ben did not say when his ROO framework might be made publicly available. Here’s hoping for sooner rather than later!