Understanding Microsoft's Indigo

Indigo has been in the news a fair bit lately, with the latest tidbit about Microsoft trying to block Open Source clones, in this case Mono. I don't have much sympathy for the Mono guys in any case. Trying to build Open Source versions of Microsoft technology is a lot like trying to make vegetarian dishes using meat substitutes - the whole idea is wrong-headed and limiting. I don't know why they even bother, and why they aren't spending their time more usefully in strengthening the true alternatives to Microsoft technology (Java/J2EE on Linux).

But let's leave the Mono crowd to stew in their own juices.

What *is* Indigo, anyway? Microsoft has a good introductory page describing the technology, but it wasn't good enough for me. I needed something to compare against. As an architect, I like to think of technology capabilities rather than products. And being Java-trained, I think of capabilities as being described by abstract interfaces rather than concrete implementations.

The closest that Microsoft's page came to describing Indigo in this way was the table comparing Indigo with earlier Microsoft technologies. It still wasn't good enough, so I created another table, expressing the same capabilities in more generic terms. Now I had a framework to compare not only the two generations of Microsoft technology, but also Java/J2EE equivalents.

Java technology relies on a single API standard with multiple independent implementations. Microsoft technology is generally represented by just a product, which blurs the distinction between the technology standard and its implementation. I've tried to cut through the confusion using the table below.

---

	Capability ->	Basic Web Services	Newer Web Services (WS-*)	Native Remoting	Messaging	Distributed Transactions
MS/ .NET	Standalone Implementation /Technology	ASMX	WSE (initial implementation of emerging standards)	.NET Remoting	MSMQ	Enterprise Services
	Integrated Implementation/Technology	Indigo (subsumes all the above technologies and products)
	Capability ->	Basic Web Services	Newer Web Services (WS-*)	Native Remoting	Messaging	Distributed Transactions
J2EE	Technology Standard (API)	* JSR 101 (XML-RPC) * JSR 109 (Enterprise Web Services - WS-I Basic Profile) * JSR 110 (WSDL manipulation) * JSR 155 (WS Security Assertions - SAML) * JSR 172 (Web Services for mobile clients)	* JSR 109 (WS-AtomicTransaction) * JSR 115 (WS-Trust) * JSR 181 (WS-MetaDataExchange) * JSR 183 (WS-Security) * JSR 208 (WS-Choreography) * JSR 261 (WS-Addressing) * JSR 265 (WS-Policy) * JSR 921 (WS-ReliableMessaging)	* RMI * RMI-over-IIOP (J2SE technology)	* JSR 914 (Java Message Service - JMS)	* JSR 907 (Java Transaction Architecture - JTA)
	Standalone Implementation	Apache Axis	(emerging)	David (academic implementation)	SwiftMQ, SonicMQ	SimpleJTA, Atomikos TransactionsTM
	Integrated Implementation	Any J2EE Container (WebSphere, Weblogic, JBoss, etc.)

As you can see, Indigo appears to be a major technical achievement when compared to the earlier generation of Microsoft technology, but it's old hat when compared to Java technology. The capabilities of Indigo have existed in J2EE for ages!

Yes, folks, it appears Microsoft has at last managed to implement a J2EE container ... minus EJB capability :-).

Move over LAMP, HILTS is here

While the corporate world is slowly gaining awareness of the LAMP stack and the more clued-on Open Source world is beginning to explore some new alternatives, a far better stack of Open Source technologies has quietly emerged.

I call it HILTS, which stands for Hibernate-Ingres-Linux-Tomcat-Spring. As a platform for running enterprise applications, I believe it represents the best that you can get for love or money.

We won't waste time arguing the strengths of Linux. Linux is the operating system of the future on every hardware platform imaginable, and when the Microsoft dazzle wears off in the near future, the rest of the world will see that too. Linux should absolutely be your OS platform of choice.

Ingres is quite simply the best Open Source database out there, bar none - better than Firebird (Interbase), better than PostgreSQL, better than MaxDB (formerly SAP DB). Notice that I don't consider MySQL worth mentioning as a competitor. Ingres has true enterprise-class features comparable to Oracle or Sybase, and the documentation that comes with it is awesome. It runs on several major OS platforms, unlike MS-SQLServer. If you want my opinion, move all your data to Ingres. That's the future. [Disclosure: I developed applications using commercial versions of Ingres a decade ago, and some bias may result from the long exposure.]

Tomcat is the quiet achiever of the Java server family. It's everywhere. Every development shop runs Tomcat somewhere, and many even run it in production. Virtually every J2EE IDE bundles Tomcat. Heck, JBoss bundles Tomcat. There was a time when I thought of Servlet/JSP engines as the Genie of the Ring when compared to EJB-capable app servers, which were the Genie of the Lamp. No longer. The existence of powerful frameworks like Spring, which I'll come to in a moment, means that enterprise-class applications can run quite comfortably on Tomcat. Tomcat should be your app server platform of choice.

I'll admit I've had mixed feelings about Hibernate. On the one hand, there's no doubt that it's a cool, capable O-R mapping product, excellent at what it does. On the other, it doesn't implement a standard API like JDO, which to my standards-craving mind, is heretical. Hibernate has often made me ponder the philosophical question of whether an Open Source product can ever be considered proprietary. [Update: There is now a persistence standard, the Java Persistence API. Hibernate will implement JPA, just like TopLink and OpenJPA (formerly Kodo). Interchangeability of implementations, however theoretical, satisfies me :-).]

Ideology aside, there is a technical limitation with Hibernate. Perhaps it isn't a true limitation, because it only becomes apparent when you try to use it for purposes beyond what it was designed for. Hibernate is great at implementing the persistence behaviour of POJOs (load/store), but it knows nothing about managing that behaviour. In other words, it can persist objects perfectly, but has no idea when to do it. It needs another component to say when.

That's the beef I have with people who talk about Hibernate by itself as a replacement for Entity Beans. Simpler and cleaner Hibernate may be, but EJBs have the notion of container callbacks driven by transaction boundaries, so they know when to initiate persistence as well as how to do it. Hibernate needs to be explicitly told to do so by a Session Bean, which means that the application developer must now take responsibility for something that an EJB container did as a matter of course. It's a step backwards from EJB to Hibernate.

Ah, but not when the Spring framework holds everything together! Spring is transaction-aware, and Spring can now drive Hibernate the way the EJB container used Session Beans' transaction boundaries to drive the persistence of Entity Beans.

Spring 1.2 now also introduces Message-Driven POJOs, and with the use of Quartz, provides a much nicer timer mechanism.

I believe that with Spring 1.2, the world now has a credible alternative to EJB technology. Spring should therefore be every developer's application framework of choice.

So there you go - the entire server-side stack for your next application! HILTS will do everything you need. "Everything" implies the application of the 90-10 rule, of course. There will still be the 10% for which you may need another solution, but HILTS will comfortably handle the other 90%.

[I was toying with the idea of calling this e-HILTS, just to tell you that you'll probably use Eclipse on the client side as your development tool of choice, but it sounds too dot-comish to be serious.]

HILTS is good. Stick it to .NET, guys! :-)

Intel's Apple deal - Why it had to happen

I disagree with Robert Cringely's analysis that the Apple/Intel deal is aimed at Microsoft. I think the move has a far simpler and more transparent objective - it's Intel's obligatory response to IBM's provocative assault on its turf.

IBM has been making a lot of noise lately about popularising the PowerPC and positioning it as a more generic processor that is suitable for consumer workstations as well as for servers. Needless to say, this is a head-on assault on Intel territory. Intel makes its biggest margins on server chips like Itanium and Xeon, but its biggest revenues come from workstation chips like Pentium IV and Celeron. AMD is already costing them sleep in this market. The last thing they want is another commodity chip here.

The AMD genie will not be so easy to put back in the bottle, but PowerPC can possibly be nipped in the bud (Nice mixing of metaphors there ;-).

Q. Who's the largest non-IBM user of PowerPC chips?
A. Apple.

So, strike a deal with Apple and pay them whatever it takes to move to an Intel hardware base. True, that's not much of a market share gain, - barely three percent, as Cringely points out. But the move is not so much about gaining market share as it is about stemming a future loss.

It's about positioning PowerPC where Intel wants it - as an IBM-only chip that no one else will touch. Once Apple is taken out of the picture, the only significant users of PowerPC will be IBM's own pSeries and iSeries divisions, which hardly counts as industry endorsement. HP will stay loyal to the Intel architecture, as will Dell. Acer and the second rung of OEMs will do likewise. Lenovo, not being a division of IBM, will see no market reason to sell PowerPC-based consumer workstations. As long as there is no PowerPC port of Windows, there is really no mass market there.

At a single stroke, Intel has put PowerPC back in its box. The only way PowerPC can ride back into the consumer workstation market is on the back of Linux, but that's a market where it already plays and where it has made virtually no headway against Intel and AMD.

Compared to the future revenues salvaged by stemming the advance of PowerPC, anything that the Apple deal must have cost Intel is probably chicken feed.