Does my bus look big in this?
I watched QCon presentation from Martin Fowler & Jim Webber over at infoQ (great site) this morning. It’s entertaining, informative, presented by smart people, based on rational judgments but it still smells a bit to me.
They argue very coherently that current ESBs are not the dog danglies (as we would say in england). They do this via an agile manifesto that while comforting to all stuck in corporate hell really fails to address the key point, that enterprise integration/messaging are very very hard, like parallel algorithm hard.
Putting aside the obvious agile agenda here, the root issue for me is that the WS-* and REST camps don’t represent a binary decision. They are extremes upon which we try and map to the simplest but no simpler. It’s hogwash to suggest that a REST model is good enough for anything, it’s just about good enough for web pages and really very little beyond that. It’s equally hogwash to think WS-* is a panacea, it creates as many difficulties as it solves.
The real question is where is the middle ground that is better than both, maybe this really is like parallelization, fundamentally hard with little prospect of a solution, just some pills to take away some of the pain.
Spaghetti lives
I used to think code spaghetti was one of the worst types of complexity you can have to deal with. I have just found another form of spaghetti that might actually be worse, fuel-injected engine wiring.
This is a new Yamaha R1 2007 engine being retro-fitted to my little sprint car. The car is a westfield that I built a few years a go while taking a break from the software world. Sprinting is a fairly low-key motor sport in the UK that involves timed runs over mostly open circuits. Here is a westy in typical sprint action.
The R1 is part of a plan to make us competitive in our class and have a bit more fun along the way, its always about performance with me…
Java v3 or JVM v3: To kill a creosote bush
Tracing JIT for Javascript
This looks important. Smart guys from UC Irvine have developed a technique for getting significant performance gains in a JVM using a much simpler (and therefore smaller & cheaper) JIT model. The Adobe team behind the Tamarin VM for Javascript have announced a branch which is trying to use this technique. The original paper shows gains of 7x over interpretation against 10x for Hotspot. It’s easy to get mislead by micro-benchmarks but lets hope this materialises into gains on everyday workloads.
JAXB Scalability
Here is some more on JAXB performance, the graph below shows the performance of the JAXB 2.0 Reference implementation and the Apache JaxMe project as the size of a data is increased for a trivial address book mapping. It also shows what happens to the JAXB-RI performance when schema validation is turned on, not a pretty picture. 
This is better than I had seen elsewhere because at 10k (about 13.5 on the graph) we are getting ~80% of peak performance. Obviously using JAXB with smaller messages or with validation on may be damaging to your applications health. The graph for marshaling is below, this is a much more healthy for small messages but validation is again very costly. 
Profiles for these runs shows that un-marshal performance is being governed by startup time and the maximum speed of the XML parser. When marshaling the parser startup costs are obviously not a factor and so the results are more linear. In either case turning on schema validation has a dramatic effect.
SIMD Code Generation, from Java?
One of the tricks to making good use of SIMD performance is to know all the parameters of the problem, it’s an 8×8 matrix or a 128byte vector etc. etc. In practice though this is really hard in a number of domains, that kind of information is not known until the code runs. For that type of an application template-based metaprogramming for C++ may be a real bonus. A couple of libraries that use this approach are Macstl & EVE.
My question, what do you do from Java & please don’t suggest JNI is quick enough 
What’s with JAXB Performance?
I have been doing some rough benchmarks on JAXB 2.0 performance and there has to be something wrong. A couple of samples I have tried work out at mapping speeds in the 4-5MBytes/sec range. This is really poor in comparison to the speed of modern XML parsers, even parsing with full schema validation is quicker than this using stock processors.
The WS02 team did some benchmarks a while back that show 3k requests/sec. Despite the claim to the contary this is pretty poor for modern hardware but we will ignore that for now. What is odd though is throughput is not at all constant, it really degrades with smaller messages which are of course the SOA bread & butter. The small message performance matches what I am seeing. I am guessing there has to be some serious start-up costs in the JAXB 2.0 RI to get this type of profile, either that or the up-scaling of the tests is causing odd things to happen. Time for some more digging I think.
Intel XML software suite is released
The XML software suite has been released, it’s at http://www.intel.com/cd/software/products/asmo-na/eng/366637.htm. Be interested to know what you think about it.
There is some press coverage at TechRepublic, NetworkComputing, InformationWeek and SDTimes.
Data layers
I have become rather interested in understanding the interplay between all these data access technologies that keep spouting around our feet. SDO and the ADO.NET Entity model appear to be charging towards a new level of abstraction that is well overdue.
ADO.NET appears to have the lead here based on being able to leverage the LINQ model to give a better programmer experience. However if invokedynamic and closures come to Java this might change rather quickly.
The kicker in this is usually not how high you can go but what you lose in the process of getting there. It will take a while to understand what has been traded but it’s an interesting area to watch never the less.
Busy
So it’s been a while…. Much happening to keep me busy; the big event has been the release of the Intel XML Library beta, see here if you fancy having a look. There are Java (JAXP dropin) and C++ versions to play with.
I also got the chance to write up some details of the processing model for Extreme Markup Languages 2007, the paper describes the model we use to process very large (1GByte size) documents.
leave a comment