Saturday, October 08, 2005
Been away, but that'll have to wait for another post...
Reading Udell, and his quote from here:
While CORBA et el succeeded at the platform elements excellently, and interop wasn't the best between vendors (or indeed between versions from the same vendor I*ahem*ona*ahem), will web services really succeed at the platform elements? Will WS interop ever really gain traction at the transaction, RM, routing elements? It's hard enough to get two or three vendors to work correctly at the API level (say for transactions) without bringing other peoples' network stack into the game.
Jon also mentions:
Going back to the cross-enterprise point, I think this goes along with the idea that the farther apart the systems are -- in terms of control / platform / etc, NOT location -- the less you want to rely on layers of interop between them. Simply minimise the number of moving parts.
This is where the REST crowd have an advantage, by minimising the ambition, they are more likely to succeed.
Reading Udell, and his quote from here:
[DCOM, RMI, CORBA] are about a platform. CORBA was 95 percent API, 5 percent interoperability. Web services is zero API and 100 percent interoperability.me thinks this is a good point. Of course, the corrollary is probably true.
While CORBA et el succeeded at the platform elements excellently, and interop wasn't the best between vendors (or indeed between versions from the same vendor I*ahem*ona*ahem), will web services really succeed at the platform elements? Will WS interop ever really gain traction at the transaction, RM, routing elements? It's hard enough to get two or three vendors to work correctly at the API level (say for transactions) without bringing other peoples' network stack into the game.
Jon also mentions:
...cross-enterprise Web services is a marginal use case -- the real value is in "getting different technology systems to interoperate within the same enterprise."
Given the tendency of enterprises to absorb other enterprises into themselves, the inter- versus intra-enterprise distinction is yet another fuzzy boundary. But assuming we can draw that line somewhere, isn't the higher cohesion afforded by a "platform" just the sort of efficiency that Sessions recommends exploiting within a system boundary?I've worked in places where the intra-company divisions are more separated than inter-company ones -- it's largely down to budget lines and motivation from up on high. In that type of place, a consistent platform is not a luxury you can hope for. I tend to think, that in practice, many systems will be stuck to together like they always have, with bits of custom code -- the real difference will be going forward it will be XML and in-process glue. In general there will always be something that doesn't quite work for your system. The platforms that will succeed will be that ones that make it possible to apply glue (whether by providing hook points, scripting environments, pluggable endpoints etc). otherwise, we'll be writing Perl / Java/ whatever intermediaries with lots of hacky transforms etc to make things work. At least with web services, we can read the messages without needing to unpack binary streams...
Going back to the cross-enterprise point, I think this goes along with the idea that the farther apart the systems are -- in terms of control / platform / etc, NOT location -- the less you want to rely on layers of interop between them. Simply minimise the number of moving parts.
This is where the REST crowd have an advantage, by minimising the ambition, they are more likely to succeed.
