jBITs

At the DDD Europe conference.. Recently, I visited the DDD Europe  conference, where Vaughn Vernon held a talk on using Akka an the Actor model to implement applications, based on the principles of Domain Driven Design. This talk, combined with some recent issues I've been facing at my customers site, inspired me to think about the design issues you face when developing multi-time applications. But let's start with what Vernon was talking about at his talk. Vernons talk His main premise: the Actor model is a more simplified model for application development, while at the same time providing a thread-safe environment to fully make use of the ever increasing number of cores processors have. While CPUs don't get any faster, in terms of pure clock speed, they do get more cores, and the we need to adapt our software to make use of these multiple cores. Traditional programming models don't scale nicely because of IO waits causing the software to block and the CPU being ...

Abstract Danny van Heumen , my co-worker at GROUP9 , has written a series of blog on his thoughts about Object Oriented Programming. In this blog I share my views on his ramblings ;-). The TL;DR version: I argue that his notion on access-modifiers and seemingly strange design choices are not caused by the design choices themselves but by not viewing OO design at the package level and the often seen way of defining packages in Enterprise applications where packages don't expose a clear, minimal API towards other packages. On access-modifiers At GROUP9, we've been discussing a  bit about object oriented programming and designs and how to do it "right". In his post on access modifiers  as part of a larger series of posts on OO, Danny argues a lacking access modifier and argues that the protected access modifier (the context is Java here) allows to wide access. I'm missing the actual explanation of which access modifier he's missing, however I'm presu...

Introduction For my current job, I'm designing the architecture for a new system. Given the set of requirements - which of course I cannot go into due to secrecy reasons - an OSGi capable environment may be one of the solutions we're looking into. Also, being able to use a standard JavaEE programming model is also requested. Given these requirements, we narrowed our choice of JavaEE servers down to: GlassFish , more specifically the new 3.1 release SpringSource dm Server In the next couple of postings, I'd like to keep you informed on the progressions and testing results we see for GlassFish, as this is currently being investigated. Most posts will be short and focused, covering just a single issue we encountered. GlassFish 3.1 - a first test In this post we'll discuss some issues with getting the OSGi capabilities up and running. The long story is below, or you can just skip to the solution at the end. One of the main reasons we like GlassFish, especial...