Right tool for the right job

I've always believed that consistency matters, whether it be at the architecture or the technology level. Its just much easier to manage a team with differing abilities if there is a consistent model and implementation.

I'm fortunate however in that I've picked technologies that actually work. Pity two fools that I heard on the floor of JavaOne (Moscone South if I remember correctly) they were arguing, well lets say talking at each other, about the merits of two different Ajax libraries (I have no clue which). The discussion was annoyingly loud and annoyingly stupid. At one stage however there was a work of genius

One chap (lets call him Fred) said

"Yeah, but at least we agree that you can do anything in Ajax"

To which his friend (lets call him Bert) said

"Yeah, there isn't anything you can't do"

A chap wandering past threw in one of those conversation grenades that leave the discussion dead and the participants suffering shell shock

"Try writing a VOIP client"

Personally I nearly exploded trying to hold in the belly laugh that wanted to get out. The point was brilliantly made. Consistency is good, but make sure you are at least in the right technology ball-park for the problem you are trying to solve.

Consistency matters, but don't be consistently stupid

Technorati Tags: SOA, Service Architecture

Ending JavaOne with a crash

Well that was a dramatic finish to JavaOne. Myself and Duane were due to do a repeat presentation today at JavaOne on SOA Level Setting around the OASIS SOA Reference Model. Duane emailed me earlier in the day to say that he had been very sick over night and had just been to see the Docs. I told him I'd fly solo but the Canadian Billy Idol vowed to carry on as only a man ignoring the bloody obvious can.

Looking like crap we kicked off and it was going fine, in fact we made it to the last slide and then it went a bit like this

Me: You okay?
Duane: No I need to sit down
Me (to audience): Sorry about this Duane has a bit of a virus....

I then turn around and see Duane taking a bit of a kip on the floor, he'd gone from upright to horizontal in one seamless motion, brilliantly meaning that we avoided a Q&A session. After a short trip to the medical centre Duane recovered and was lobbed into a cab to catch a flight back up to the frozen north.

So lessons learnt today include the all important one.... if you feel like crap stay in bed, the world will go on and you won't end up as a YouTube highlight (please tell me someone got it!)

Technorati Tags: SOA, Service Architecture

JPC - winner most mentally brilliant thing I saw at JavaOne

At JavaOne you always seen some crap presentations and you see some great presentations on things that you will never actually use in the real world. Then occasionally you wander into a presentation where people have done something in Java that is truly mental but actually has a point.

Welcome to JPC, the Java PC emulator. Yup you can run an x86 PC on top of a JVM, including running Linux. Okay so it isn't fast but this does give a great demonstration how mentally powerful modern machines are. The clever bit is around the work that they have done around compiling the x86 code into VM code.

The presenters did a good job of describing a very complex area such as compiler design and the pieces that they did.

Why though isn't this just another crazy concept that you will never use? Well first off it means that you can run x86 on any VM platform, this is important because just think in 20 years time, will x86 code from 1990 still run on the modern hardware? Quite probably not so it gives a great addition for future security of archives. The other bit where it wins over a virtualisation solution is that you could run it as a minor slave on a box rather than having to virtualise everything. If you have some ancient DOS programme that just processes and dumps a file or has a very basic green screen interface than you don't have to virtualise the entire platform before you can run it, you can just run a VM and have the application running along side the main OS. This could be quite a nice way of deploying those old crappy DOS applications on the new shiny hardware and doing that in a way that doesn't require expensive virtualisation of all those new shiny terminals.

It also has a great case (which is why a bunch of physics people did it) around grid computing as a way to provide a more scalable approach to distributing applications that can utilise downtime without requiring a local install and thus giving a nice secure environment (the JVM) for that grid code to operate in. This is one of the few (hell I think its the ONLY) practical ways I've seen to deploy a multi-purpose grid in a secure sand-boxed environment for any hardware (they demo'ed it on mobile phones, sort of like the iPod supercomputer concept but without the hardware hack).

In the presentation they actually set up a grid with people in the room, that is confidence on quality.

Oh and they are claiming they can get to 50% of the native machine in performance.... Java is so slow that it runs a PC at half speed.... in a browser window.

Mental, very clever and something you could even see a use for.

Technorati Tags: Java, Virtualization

SCA and JBI - a match made in enterprise heaven

Some technologies are aimed at developers, some are aimed at fanboy developers, sometimes however technologies are aimed at the bigger picture, how to architect, deliver and operate enterprise systems. SCA and JBI are two such technologies and there seems to be a misunderstanding around them being competing technologies. I've said before that SCA and JBI should work together so this isn't news but I think its worth quickly explaining why the various vendors need to get the politics out of the way and start working together to make SCA and JBI work together.

This is a standard sort of SCA view. So what are the good things about SCA?

1. SCA helps you think about the business services not the technology
2. SCA helps you construct services, and their teams, around a service view
3. SCA gives you a management entity that fits with a service architecture not a technology architecture
4. SCA destroys the dreadful layer marketectures that vendors push

So simply put SCA helps you build better SOA by giving you more of a SOA view of the world. The way to build good SCA is the way to build good architectures

1. Think about your services
2. Organise your teams around those services
3. Work out the best way to build each service
4. Delivery
5. Operate

The last is a brilliant part of SCA as unlike the layer diagrams of BPEL/EJB/Fish/Database etc it makes it clear at the operational level what the Service architecture is, it also encourages you to think about the services and your delivery before getting into even the design (let alone the code).

So that is what SCA is good at. What about JBI? Well lets first be clear JBI is not for developers its for product companies. JBI is one of the few standards out there (SCA is another) that actually has a business case for its existence. The various scripting JSRs and some of the other fanboy elements out there just have a technical case. This is typical of lots of IT which aims to deliver technical flexibility to the detriment of business flexibility.

So how does JBI work with SCA? Well JBI is about Service engines communicating so its not about the services its about how the engines talk together. This means that it works underneath the services. Combining SCA and JBI therefore is pretty easy

In reality the call isn't from one code area to another its really between the service engines, i.e. the bit that JBI does. The goal of JBI therefore isn't portability of the code/service its portability of the engines.

This solves one of the big issues of SCA which is that implementations are limited to a single vendor's platform. It also doesn't really have a great upgrade story so you are again linked to what the vendor wants to do, if the BPEL engine you are happy with is upgraded and the rules engine that you don't like is upgraded and they all run on the same platform which is upgraded then you have to move everything at once, which is a bit of a pain.

So the real vision here is for SCA and JBI to work together, unfortunately at the moment the JBI group is missing Oracle, IBM and SAP which makes it unlikely that this will be done. This is to the detriment of customers as it means that SCA will remain a great single vendor platform but will not have the portability and operational flexibility that JBI could deliver.

Politics appears to be getting in the way of an SCA/JBI match up as no-one I've spoken to on either side of the divide thinks it isn't technically a good idea.

Technorati Tags: SOA, Service Architecture

Boothware

I'm doing some reviewing of JavaOne presentations at the moment (SOA/EAI) and the number of vendor presentations that are basically a booth demo where they'd like a bigger audience is just staggering. Sometimes they are dressed up as an "investigation" but most of the time its literally a standard booth demo (even including "how to install" on occasion).

Death to Boothware.

Technorati Tags: JavaOne