So here's my interpretation of the information revealed at the PDC thus far. This round, I'm going to list my view of Microsoft's "goals" and what this could mean for alternative frameworks / vendors.
In my opinion, some of Microsoft's goals are:
a) In the enterprise, information-based applications rule: traditionally they have been VB applications, lately they have been web applications, some are even Java/Swing applications. One of Microsoft's biggest battles has been to hang on to that client-layer lock-in that is continually eroded by web applications, and is the #1 reason why Linux is even considered a palatable alternative in the enterprise: develop on the Web, deploy anywhere (in theory). Develop on Windows, you must deploy on Windows.
Longhorn's goal: Fuse together Windows development (XAML) and Web development (ASP.NET), so the two are fundamentally the same set of development tasks - the differences are relatively trivial, except that Windows applications will be richer.
By doing so, it won't be much effort to convince people to use the rich application features of Windows. It's an old story, but it makes sense: keep providing the path of least resistence to your system, and make it compelling. That will slow the tide.
I notice a lot of developers drooling over XAML, and it looks very pleasing, but the idea is fairly predictable, and has popped up in a number of locations: it's an evolution of the traditional notion of "GUI setup as resource file" vs. "GUI setup as big init() method". The evolution looks like a promising one.
b) Indigo's goal: Unify all the disparate Windows communications / enterprise technologies (Transactions/MSMQ/SOAP/Serialization/etc) into a common and SIMPLE framework that's competitive with J2EE. Allow extensibility at every point and make every feature dependent on an open specification (the WS-* specs).
Some would say .NET is ALREADY competitive with J2EE, and I would agree with that in terms of ASP.NET vs JSP/Servlets. But I think Indigo is necessary to make it competitive with JMS/MDB's. There already are large services-oriented archtiectures out there based on JMS, MQSeries, and J2EE, and this is in fairly mainstream financial institutions (and a certain telecom company seems to be moving in that direction). Microsoft needs to provide an alternative to this model unless they want to see J2EE retain its lock on the server.
Anyhow, this has been long a goal for Microsoft, and I'm glad it's finally here. I was suspecting this was what Indigo would be, and I'm pleasantly surprised that it's looking like a very simple model. I will be attending some of the Indigo sessions today to get a more in-depth glance.
Indigo continues Microsoft (and IBM's) approach of "changing the game" and "leading the charge" in writing the "new distributed computing standard". Microsoft and IBM still have the upper leg here because they control the key specs thus far (until WS-I takes them over).
A lot about Indigo and consequentially, WS-*, is about re-creating CORBA after 10 years of experience: the protocol must not make assumptions about the execution environment's structure or process model for any particular feature: (e.g. session-oriented security vs. message oriented security, object orientation and inheritance of interfaces, etc.) The specifications in CORBA made too many assumptions and made implementation too difficult for that reason.
In the autonomous computing / web services world, the protocol is all that exists, and all that you can rely upon.
Another interesting observation: If Indigo is released with Longhorn in 2006, it will be released around the time of J2EE 1.5 and EJB 3.0. That makes for an interesting competitive situation, considering Sun's goal for J2EE 1.5 is "ease of use". Hopefully this rivalry will benefit all developers in the long run: it certainly has improved Microsoft's offerings by an order of magnitude, in my opinion. I hope Sun will get over its current identity crises and step up to the plate.
I also would hope some in the OSS community will step up and start thinking about a similar model for non-Java oriented systems. I've heard lots of posturing from some folks about this, but nothing of substance yet.
c) Yukon's goal: (well one of them) -- bring business logic back into the database. And unify caches among tiers.
In allowing .NET languages inside the database, this fixes a long standing problem: logical 3-tier out of necessity has had to be physical 3-tier, because our databases have not supported the rich languages and frameworks we use to write our business logic. When running through reams of data across the tiers, this is can lead to slow, unscalable applications, only fixable by placing an (unacceptably high) amount of logic into stored procedures / T-SQL or PL/SQL.
Of course, for scalability reasons, not EVERYTHING should be in the database, but a lot of business logic is validation logic and needs to be as close as possible to the data.
Assuming C# flys through data as fast as T-SQL, this will hopefully give Oracle the kick in the pants to speed up its Java integration in the database, or at least provide some sort of integration solution between the application server and the database.
And hopefully Oracle will provide a cache dependency feature between the database and application server: it's frustrating that after years of EJB users asking for this, it took Microsoft to come up with it first (in beta at least)!
More to come...
Posted by stu at October 28, 2003 08:43 AM