Mark Little added this interesting comment to my previous blog entry:
Now, here's a question: assume we could roll back the clock to 1989 and get MSFT to join the OMG in the same spirit as everyone else. Further assume that this lead to CORBA dominating the desktop as well as backend systems (not such a wild idea given the first assumption). Do you think we'd be here today with WS as we know it now? Would it have happened earlier, or not at all?
CORBA's complexity, whether necessary and warranted or not, is what turns most people away from it. If Microsoft would have been an active OMG member during the formative years of CORBA, would their presence have prevented CORBA from getting as complex as it is? IMO the answer is clearly no -- one need look no further than COM to figure that out. But if MS had been involved, they and their tooling, even if it had just been VB alone, might have hidden that complexity to the degree that CORBA would have at least ended up being more palatable and useful for a much broader audience.
Nevertheless, because of that complexity, I don't even think that Microsoft's full participation in the OMG and CORBA would have been enough to stem the tide of WS as we know it today, simply because of the way that technology markets work. In fact, I think their involvement might have brought WS into the picture sooner, because I think the whole sequence would have happened faster. When a technology is perceived as too complex or too expensive (regardless of whether the perception is technically correct or not), and there's money to be made there, someone invariably invents a new disruptive technology to displace it and take its market. Whether WS is a reinvention of the wheel, is technically inferior, or will eventually wind up just as complex as CORBA or COM or J2EE or anything else simply doesn't matter, because the market and technology adoption life cycle isn't governed strictly by technical goodness.
Comments (5)
Hi Steve. It was probably an unfair question to ask in the first place, since I doubt it can be answered objectively, but it's fun to speculate anyway :-)
I'm not sure I agree 100% with you. I think tooling and abstractions/architetcures are obviously important, and SOA is better for some types of applications than others. I just wonder whether, given the MSFT-joining-OMG assumption I originally asked, would SOA/WS have been a separate technology from CORBA, or a more natural evolution of CORBA? (Oh, and I naturally assumed that Sun had been more actively involved in the OMG too ;-)
Anyway, let's introduce this other variable: let's further assume that the firewall vendors had been more CORBA/IIOP friendly in the first place and "tunnelling" IIOP through the corporate firewall was easier 7 years or so ago (sorry, I can't remember the exact OMG meeting where I first saw the spec. on firewalls, so it may have been even longer ago.)
Posted by Mark Little | October 6, 2004 8:29 AM
Posted on October 6, 2004 08:29
Mark,
Yes, I think it was over seven years ago that the OMG started working on firewall specs and they never really did get far did they.
I don't think the introduction of this variable would make a huge difference - if you had said "the CORBA vendors had been more firewall friendly" then I would have be curious.
As the new boys on the IP block, the onus was probably on the CORBA community/vendors to be friendly and get their products to work with existing firewall implementations - after all the firewall guys owned the IP gates.
A couple of eveb obvious barriers seemed insurmountable by the CORBA vendors.
* ORB vendors didn't make it easy enough to restrict server port usage to configured/assigned port(s) rather than a daemon assigned port from a port range that was typically oversized. Large port ranges were often configured for no good reason a lot of the time (in case a port got 'worn out' I was once told!)
Have a look at any firewall config - there are not that many ranges of ports open - doing so makes network admins uneasy (hence the reason passive rather than active FTP connections are more common)
* Inherent in the distributed nature of IDL systems - callbacks. Again the inability to easily restrict the target ports (in some Orbs it was impossible to specify ports for callback objects) made it impossible to deploy.
Usually it was within the realm of the ORB configuration, sometimes code changes were required in order to control this aspects of CORBA clients/servers. Implementations improved when the POA ORBs appeared but that was probably a little too late.
They never really got past those initial hurdles so grand visions of IIOP message routing through multiple firewalls (using additional firewall IIOP profiles for routing) was always destined to fail given the relative complexity and the administration overhead such a model imposed on the largly CORBA ignorant network admins (again, a lack of understanding)
What is probably the most surprising thing about the about the migration to SOA/WS/message-centric architecture was that in reality firewall admins don't seem to care that external applications are sending applications calls(SOAP) into their enterprises via of HTTP - for most, their primary job is keeping their familiar HTTP infrastructure (proxies, firewalls) solid.
I would argue that this may change and they _will_ care very much what messages are being passed in and out - it's a lot easier to filter/control nice XML document content than yukky binary IIOP. Even rpc SOAP messages might be considered slightly too hard to work with on the wire...
j.
Posted by Aehso | October 6, 2004 1:40 PM
Posted on October 6, 2004 13:40
Hi Mark,
Yes, the question was unfair, which means I no longer owe you a beer. ;-) But I agree that the speculation is fun.
I don't think firewall support would have made too much difference. The reason is that IMO it was the complexity that was the big CORBA hurdle that most couldn't get over. Not trying to sound smug here, but let's be honest: only a small percentage of the world's developers can handle CORBA's complexity. Even if MS had been CORBA bigots and put their tooling support over it, they still wouldn't really have been able to hide the complexity (which is what I tried to say in the blog entry but not sure I said it clearly). So it comes down to what I said before: a big reason that WS appeared on the scene was to try to circumvent the complexity of things like CORBA, DCOM, and J2EE so that more developers could build actual, working systems.
Posted by Steve Vinoski | October 7, 2004 12:51 AM
Posted on October 7, 2004 00:51
Hi Steve. I think we can agree that in some sense WS (or SOA) was inevitable. How and when it would have come about given the input of MSFT is an interesting debate that we can continue over a pint: and you do still owe me one ;-)
P.S. Eric and I just finished the WS-CAF face-to-face in Dublin, where the Guiness was, as usual, nectar from the gods.
Posted by Mark Little | October 7, 2004 6:05 AM
Posted on October 7, 2004 06:05
Hi J. Yes, you're right: I didn't mean to imply that the onus was on the firewall vendors to get more in line with the OMG.
As for tunnelling: I remember sitting in one of the first OMG meetings where the firewall RFP came up and people were discussing how http was being used to tunnel all sorts of things through (and that was 7 years ago). The comments then were pretty much the same as you just made: surely they'll stop this soon and start inspecting the packets. Still hasn't happened. (BTW, I agree, it should.)
Posted by Mark Little | October 7, 2004 6:09 AM
Posted on October 7, 2004 06:09