One of the problems I find at many of my clients is that it's easy to forget that interoperability doesn't come for free - it doesn't matter whether you're talking about file formats between systems (witness the interminable and unbelievably dull discussions you can read everywhere about .odf, etc) or whether you're talking about Java programs (do you want to use the new stuff in 1.5 or do you want it to run on old JVMs?) and it certainly doesn't come for free when you're talking about web services.
The key point is that if you want your web service to be consumable by tools other than the one that created it, you need to tell your tooling that this is what you want. (Some tools will default to this behaviour, others may default to whatever that vendor prefers or what version 1 of their product used or whatever... the point is that you at least need to check... don't assume!)
However, even if you check all the right boxes, you still need to be sure your vendor really can interoperate with others.
So I was delighted to see this post on the JBoss blog. I always had a vague suspicion that the vendors must work with each other to check that their products interoperate but it's something I hadn't given much thought to (since my experiences have suggested that, with the right care, interoperability can be achieved).
The importance of the JBoss post is that it shows that interoperability really has gone further than making sure you can invoke a .NET "stock quote" service from WebSphere and is now in the territory where real value lies: distributed transactions...
2 comments:
aaaah...have you been paying attention to RSS?
Hi Dennis - which bit of RSS?
I have to admit that I am utterly bemused by the holy wars over Atom and RSS. I just don't care enough even to think about it....
But, even given such silliness, interoperability does seem to work pretty well at the level of feed subscriptions.
However, I guess RSS sort of proves the same point: being able to subscribe to a feed is equivalent to "get stock quote".
Being able to manage "unread" marks, deal with comment feeds and automatically update feed readers if a post changes, etc, etc, is much harder and can perhaps be considered analogous to the harder problems in web services (e.g. TX, security, etc)?
Post a Comment