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.
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 | ||||||
| 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 | ||||||
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 :-).
No comments:
Post a Comment