The Data, Context, and Interaction (DCI) architecture paradigm introduces the idea of thinking in terms of roles and contexts. See some of my white papers for a more detailed introduction into DCI, but for this blog article, consider the following example: a human could be modelled in object oriented programming by creating a super huge massive class which encapsulates all a humans attributes, their behaviours, etc. You would probably end up with something much too complex to be really maintainable. Think about when a human becomes a clown for a kids party; most of that behaviour has little to do with being a programmer, which is a different role which the human could play. So, DCI looks at the problem differently than OOP and solves it by letting the data class be good at being a data class, and putting the behaviours specific to certain roles into "roles", which in my DCI Tools for Java library are classes. Certain roles interact with each other within a given context, such as a clown entertaining kids at a birthday party. The roles which belong to an interaction are part of the context, and in DCI the context is a class which puts data objects into specific roles, and makes them interact. The context and its roles form the encapsulation of the behaviour. I have updated my library, so that there are two new Annotations, namely the @Context and @Role annotations. The @Context annotation is simply a marker to show that a class…
Category: Uncategorised
User Mental Models
I've spent the last 6 weeks looking into an interesting paradigm called Data, Context & Interaction (DCI). I've written a few introductory papers, and some tools too. DCI has the following goals: To improve the readability of object-oriented code by giving system behavior first-class status; To cleanly separate code for rapidly changing system behavior (what the system does) from that for slowly changing domain knowledge (what the system is), instead of combining both in one class interface; To help programmers reason about system-level state and behavior instead of only object state and behavior; To support an object style of thinking that is close to peoples' mental models, rather than the class style of thinking that overshadowed object thinking early in the history of object-oriented programming languages. The problem recognised by this paradigm is that system behaviour gets fragmented in traditional OOP, over a large number of classes and sub-classes. The code directly related to a use-case gets fragmented and "lost". The boundaries for the behaviour end up being class boundaries and pieces of behaviour are stuck with the data on which they operate, so that the code has high cohesion. If you want to read the code related to a use-case, you will struggle to extract it and understand it. I agree with these problems, but have not really encountered them personally for a long time, because I do most of my work predominantly in the SOA paradigm. When I first read these goals and all the articles I could…
Taking Advantage of Parallelism
A while ago some colleagues attended a lecture where the presenter introduced the idea that applications may not take full advantage of the multi-core servers which are available today. The idea was that if you have two cores but a process which is running on a single thread, then all the work is done on one single core. Application servers help in this respect, because they handle multiple incoming requests simultaneously, by starting a new thread for each request. So if the server has two cores it can really handle two requests simultaneously, or if it has 6 cores, it can handle 6 requests simultanously. So multi-core CPUs can help the performance of your server if you have multiple simultaneous requests, which is often the case when your server is running near its limit. But it's not often the case that you want your servers running close to the limit, so you typically scale out, by adding more nodes to your server cluster, which has a similar effect to adding cores to the CPU (you can continue to handle multiple requests simultaneously). So once you have scaled up by adding more cores, and scaled out by adding more servers, how can you improve performance? Some processes can be designed to be non-serial, especially in enterprise scenarios. The Wikipedia article on multi-core processors talks about this. Imagine a process which gathers data from multiple systems while preparing the data which it responds with. An example would be a pricing system. Imagine…
Oracles Sun Forums Are Crap
Rant Time: I've run in with the forum moderators before, but this really winds me up. I searched on Google for "java open browser", to remind myself which API to call to open the default browser, and the number one search result was this: http://forums.sun.com/thread.jspa?threadID=679673 The answer is at the bottom of the page. Perfect. But then Darryl Burke comes along and locks the thread, because he reckons this latest posting is useless. Sorry, but Sun Forum Moderators don't get the concept of how forums are searched and used! They once told me they lock the threads because they want you to post new threads. I don't have the time to make a new thread asking a question every time I can't solve something, and then wait and hope someone with the answer comes along over the next few days - I want to search for it ,and find the answer immediately. If they keep locking threads, you end up with hundereds of old locked threads which don't help anyone. What their vision is doing, is simply destroying the internet! Idiots! And that is one reason I don't post to their forums anymore - they are the losers, not me.
Auto-update of Midlets
Any professional application should be capable of updating itself over the internet. Even Midlets! The idea is fairly easy in that the Midlet needs to make a call to the server to check what version the latest software has, and compare that to the installed version. If there is a newer version available, then it needs to start the (mobile) device's browser and point it at the URL of the new JAD file. The device will take care of the download and installation after that. So, the following article shows you exactly how this can be implemented. First off, refer to the previous article, which described a framework for making server calls. The sequence diagram looks like this: Based on the framework, the following JSP can be installed serverside, which reads the version number out of the JAD file: <%@page import="java.io.FileInputStream"%> <%@page import="java.io.RandomAccessFile"%> <%@page import="java.io.File"%> <%@page import="java.util.List"%> <html> <body> <% RandomAccessFile raf = null; try{ String version = null; String path = request.getSession().getServletContext().getRealPath("index.jsp"); File f = new File(path); f = f.getParentFile(); f = new File(f, "jads/nameOfJad.jad"); raf = new RandomAccessFile(f, "r"); String curr = null; while((curr = raf.readLine()) != null){ if(curr.startsWith("MIDlet-Version:")){ version = curr.substring(16); break; } } %>OK <%=version%>| add other master data like the users details, their roles, etc. here... <% }catch(Exception e){ log.warn("failed to read master data", e); %>ERROR <%=e.getMessage() %> <% }finally{ if(raf != null) raf.close(); } %> </body> </html> This JSP is called when the Midlet starts, and effectively delivers "master data" to the device, such…
A J2ME Library and a simple HTTP Service Framework
J2ME's support for calling a server is rather simple and low level. Not only do you have to deal with the HTTP Connection at a low level, there is no high level support for cookies, authentication or remote procedure calling. So if you want to pass an object to the server and get a response, you need to figure out how to do that. XML over HTTP is one solution, but presents its own problems like the serialisation and deserialisation of objects, not to mention higher network traffic because of the meta-data held within the XML. JAX Binding is certainly not supported in J2ME-land which results in you having to use a SAX parser. In previous projects I have toyed with a simple way of providing services over JSPs, which take and receive delimited text. The idea is to implement your own simple serialization and deserialisation of simple objects allowing you to make simple calls to the server and receive simple responses. I purposefully used the word "simple" four times in that last sentence to impress upon you the idea that server calls should be kept simple. Take for example a J2ME application which tracks a GPS location. To send the location of the user it can simply send a line of text like this: 006.574438|045.453345|11022344843373 What's it mean? longitude | latitude | timestamp The serialising and deserialising of the data is VERY simple using a StringTokenizer (erm, which doesn't exist in J2ME, so see later!). And the server could…
Enterprise GWT: Combining Google Web Toolkit, Spring and Other Features to Build Enterprise Applications
The following is just the introduction taken from a new white paper available at www.maxant.ch/white-papers: Google Web Toolkit (GWT) provides developers with a powerful means of developing AJAX front ends without the worry of having to maintain complex Java script libraries to support multiple browsers and browser versions. GWT also provides support for Remote Procedure Calls (RPC) to the server. Since April 2009 the Google App Engine has existed, which allows developers to deploy their GWT applications and also provides support for Java Data Objects (JDO) and the Java Persistence API (JPA). However what is missing for GWT to be deployed to a modern Enterprise environment is a service framework providing dependency injection and inversion of control (IoC), transaction demarcation and security, such as that provided by Spring or Enterprise Java Beans (EJB) 3.0. Furthermore GWT does not define any patterns for User Interface designs, or composite widgets. This paper describes how to successfully integrate Spring into a GWT Application with the aim of creating a fully scalable development framework for deployment in the Enterprise and beyond (including simple and small applications), with very little start up time being required, because you can download the demo application. It includes UI Patterns and composite widgets to improve the development of the front end. This GWT Demo Application is live at http://gwtdemo.maxant.co.uk and is available for download at https://www.maxant.ch/white-papers (c) 2010 Ant Kutschera
Houses of Cards
I have often heard of software systems being compared to a house of cards, meaning that they were poorly built and are ready to topple at any time. The system I am currently helping to maintain has from time to time also been labeled in that way, yet it always manages to go live with quite a few new functions, and apart from the odd all-nighter to fix a few last bugs, it works to the customers satisfaction. So while I was doing the washing up today, I noticed something. I am well known amongst family and ex-house mates for building what look like unstable piles of washed up dishes, as they dry. Yet I have never ever had a pile collapse on me. Never once have I lost it all. And remember, there are slippery suds involved in holding up these piles! As I thought a little more about it, it didn't take long to come to the simple conclusion that a pile of washing up is stronger than a house of cards. Cards are uniformly shaped and have no edges or surfaces which help to lock their neighbours in place. Plates, dishes, cups, pans and cutlery on the other hand can be placed tactically so that they lock together forming a strong structure. Notice in the picture below that the heavy pan is placed at the top! It still looks ugly though. But as long as its just left to dry it will be safe. Just like our…
The Key to Maintenance is Compartmentalisation
Over the last couple of large projects I have noticed a trend in the way software developers/engineers/architects like to come out with statements like "that code is shit". I'm not just talking about me saying it, or how they react to the code that I write (come on, I write great code!). But general sweeping statements like this crop up all the time on these projects, related to everyones code. And managers then perpetuate these statements. I think the reason is easy to understand. When a developer takes over responsibility for some code they want to make it clear that any problems with that code are unrelated to them. They don't want to take responsibility for the code which someone else has written. Because writing code is inherently creative and the same functionality can be written many different ways, you are almost guaranteed that a developer taking over some code "would have written it differently". What I have also noticed is that the developers coming out with statements like this do not know or do not want to understand the conditions under which the code was originally written. As an architect, I realise there are many many factors which influence the creation of code, budget being a major one. What some developers also do not fully appreciate is that the perfect implementation not only doesn't exist (because every developer would do it differently) but that it often isn't required. The perfect solution considers many cases which don't need to be…
Java EE Security and Spring
Spring Security (originally ACEGI) does not seem to work out of the box with Java EE security (see here). I guess the reason is clear, namely that the people from Spring don't want you to be tied into Java EE and that makes sense because Spring something that you can use without Java EE. But instead of having to learn something new and instead of having to configure my security in a non-standard way, I wanted a way to ensure my services are only called by someone with the right authorization, exactly when they are deployed in a Java EE environment. Since a standard web application running in a Java EE container can be configured to have security, I expected to be able to configure Spring to use the web request to check the Principal for its security roles before calling a service, but that isn't possible. So, I set to work to quickly create a little library to help me out. The first step was to implement a Filter in the web application so that it could intercept every call and insert the web request (containing the Principal) into a ThreadLocal variable. The idea was that the ThreadLocal variable could then be used further up the call stack to query the security roles of the authenticated user. The filter implementation looks like this: public void doFilter( ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { //set the request in the security…
