I challenge the Java Hackers, read on….
As you probably all know by now, I have joined ISIS Papyrus a while ago and last week i was reading the Papyrus Objects Developer Guide again and suddenly lightning hit me and the question raised can this actually be done in Java and if so, how and how easy?
Be aware, reading further could put you in a depression but on the otherhand the real Hacker will find it a challenge. Are you the Hacker?
Based on a discussion on Linkedin i have created a Dutch post on Computable on the premises of XML and if they came true. Feel free to leave a comment there.
As many other developers, I’ve been used to the fat service layer and the anemic domain model of the transaction script pattern. In that programming model, immutability is pretty much as rare as a Dodo. However, I have been investigating the rich domain model pattern lately (as you can read in my previous post) and more importantly, a good migration path for “transaction script” developers to get acquainted with the rich Domain Model, a design pattern that has been heavily underrated (and misunderstood) by many.
In this post, I will explain some of the advantages that immutable domain objects bring us, while showing that some of the seemingly problematic side effects aren’t really that problematic.
This year, 2009, is the 200th anniversary of Charles Darwin‘s birth and the 150th anniversary of the first publication of On the Origin of Species. In this famous publication Darwin launched his notion of how species’ survival is dictated by their ability to make the most efficient use of the available resources in their environment, how they adapt to increase that efficiency and how the combination of increased procreation and targeted adaptation mean that the most adapted and adaptable species survive longest.
Much like species of plants and animals, the software we build for our customers (and the software built by our predecessors) lives in an ever-changing environment. Business needs change and expand, fashions change, economic booms, lulls and the occasional crisis follow one another in an endless tide. Software systems face their own survival challenges, dealing with all these changes. And much like their biological counterparts it is their adaptability that rules their survival.
Hippo is an opensource content management system. Hippo has created a cms on top of the Jackrabbit repository. Hippo is not the only cms that does this trick, but it is a big one. With version 7 out there, you can now use some nice features that they have created. This post discusses one of these features in detail, Workflow. I’ll explain what it is, what is can be used for and how you can extend it with business events.
I do want to stress that this is an idea I have about how this can be implemented. I did try it out, but do not consider this as a best practise (yet). See it as inspiration to your own extensions and maybe Hippo will contain something like this in the future.
The idea behind this post came from talks with Allard and Jeroen Reijn, who will write a blog post about a specific part of the solution as I will describe in the post later on.
I have once in a while discussions with Jettro on Flex, Ajax and what we do at ISIS Papyrus with our Papyrus EYE user interface. Post on Adobe`s Flex attracks a lot of visitors to our blog. So, now I ask all of you with real-world experience with Adobe`s Flex to be honest to your self and ask yourself is Flex something a business user can use to define his own User Interface? Or at least is it Flexible and manageable enough to do quick changes based on changing user requirements?
I recommend to read the two post below and also to leave your response.
Tony Byrne, analyst with CMSWatch, put out an interesting blog”The case against Flex-based application UIs“.
Max J. Pucher has written also an interesting blog-item on “Flex versus EYE“.
Using Spring, it is easy to inject any instance with its dependencies, as long as the instance is managed by the Spring container. This typically means that the to-be injected beans are configured in the XML configuration. However, sometimes, it is impossible or ugly design to have objects managed by the Spring container. For example, when using a Rich Domain Model , your application will instantiate domain objects that contain domain logic, and thus need their dependencies to be injected.
A commonly seen strategy to inject these dependencies is to call a static method from the constructor. This static method will inject the newly instantiated instance with its dependencies using a reference to Spring’s application context. Although this method seems effective, it is purely limited to dependency injection. Spring offers a lot more, such as transaction support and security.
Spring’s load time weaving capabilty offers a more complete way to inject your unmanaged instances, making them no different than any spring managed instance.
Since my last article about springframework and hippo “Roadtrip from springframework to hippo 7” I have made a lot of changes to the code and moved my project to the hippo forge. With this post I want to explain what I have changed and in some situations why. I will not repeat the stuff I already talked about in the previous post. One of the biggest areas I made changes in, is the stability of the solution. I used the Circuit Breaker implementation as discussed by Allard in his post “Bring some stability to your architecture“. Stability comes with reconnect options and a component that guards the repository. In case of to many errors the connections are closed and after a certain cool down period, new connections are created.
One remark I like to make is about the connection pool. This pool is probably not production ready. I did not do any performance tests and it is a bit rough around the edges.
That said, let’s move on and start talking about the solution.