Developers are strange. We tend to spend hours discussing which feature is the best, what language to use, which color our laptops should be.
One of the longest and most polarized discussions is wether strong or weak typing is the better. Then we go on to select a language based on our preference.
Both camps have points. Weak typing allows you a more flexible domain object tree, where you very easily can add new stuff. If you can keep control of your design, this is clearly good. Strong typing allows for more error detection in your IDE – if you use an IDE. You do, right?
I could go on and on, but the problem we tend to create through these discussions is that one tool is not best for all applications. The domain I am going to write about today is integration.
If you come from the weak typing camp, you are probably used to the idea that you can accept any object that conforms to the interface you actually need. If you need version 7 of an interface, and the producer guarantees backwards compatibility, you are probably quite happy to accept even version 10 of the interface. In cases where very good designers have been around, I have seen the client ask the producer wether it can produce data that is compatible with the version it can accept. This very seldom happens in the software world. This is mostly the domain of hardware designers. My macbook is able to detect wether an external display only has a resolution of 800×600, and adjust accordingy. This type of negotiated versioning is my personal favorite – but then again, I have a hardware background.
Other camps accept whatever they get, store it away, alert someone, and then hope someone upgrades the application before the information that is available in the new version is needed. The benefit of this is that the problems gets pushed forward in time, and does not create problems until the very last moment when the information that is unparsed is actually needed. There are benefits and drawbacks to this solution, but it has worked very well for those who are able to view their integration points as a document.
Imagine adding strong typing proponents to this mix. Strong typing means knowing exactly what your objects can look like. My macbook would only accept the 30″ apple-branded displays, making it unusable when I want to present at a conference with an unknown projector. This is where 95% of the integration platforms out there are. To me, it seems like this branch of integration platforms has grown from the language-supported method call interfaces we use internally in our applications, through CORBA, then we did the same thing again only with XML and got web services, which have now evolved into JBI, where stuff looks like documents, but are very strongly typed. These technologies seem to cause teams to make only token efforts towards governance. I have found none who are forward-compatible.
I come from a company where people have been thinking about this for some time. These people have now moved on, but the ideas are still around. One of the ideas brought forward by this bunch of people is to do away with most of the web services stack and use xpath to pick out the bits of a message you need. If elements you don’t recognize and don’t need appear in the message, the extra information is ignored. More information from these people can be found at the Cantara wiki.
So – where am I going with all this? I am a proponent of strongly-typed languages. I have seen too many projects fail because most developers lack the discipline necessary to avoid abusing a weakly typed language. That is why I prefer Scala to Ruby.
I am not a proponent of strongly typing everything, though. Strong typing is a good idea inside an application. Anything that is outside the application is going to be less under the control of the developers than whatever is inside. This is a fact. Nothing to do about it. Therefore a different approach is needed in order to avoid hideously large development/maintenance costs. This other approach is going to cost the team more, but the cost is going to be lower than trying to treat the outside world as something that can be controlled. I am not even sure I would want to do that – the implication is that the slowest team in the outside world is going to control the speed of your team, too.
This is where my gripe lies. I want to be able to selectively select how weakly an interface should be typed. When I assemble interfaces, the typing should affect how they interact. Right now, there does not seem to be a language that allows this. All languages have a one-size-fits-all approach to typing which is going to be wrong sometimes. The best compromise I have been able to find so far is the cantara or spring integration approach with the strongly-typed Java.
Perhaps in ten years…