All About Interop : RSS

Fact Check – IBM’s Steve Mills claims on MS and SOA

DotNetInterop — Fri, 10 Aug 2007 03:13:00 GMT

We saw an article on CNET that included quotes from Steve Mills of IBM directly related to Interop, SOA and Microsoft. Since Interop is one of our passions, we thought it would be worthwhile to respond. Given that we are approaching an election here in the US, we are employing a CNN technique. Let's check the facts.

Claim: Steve Mills is Senior VP of IBM Software.

Microsoft Fact Check: TRUE. Mr. Mills runs IBM Software, which is about a USD $18B business for IBM. By the way, IBM Software Group contributes about 40% of IBM's pre-tax profit, according to a recent ComputerWorld article.

Claim: Microsoft's approach to SOA [is] stymied by its emphasis on linking Microsoft-compatible processes. "We're doing all platforms; all applications," IBM Software Group executive Steven Mills told ZDNet.co.uk. "We're integrating everything. Microsoft is trying to provide connectivity capabilities for those that are running on Windows platforms. That's a profound difference."

Microsoft Fact Check: Mr. Mills seems to be commenting on Microsoft SOA infrastructure software, including the .NET Framework (and WCF, and WF, and all the constituent technologies), BizTalk Server, Host Integration technologies, and so on. If the claim is that this Microsoft software runs only on Windows, then this is TRUE. This is not a particularly novel, interesting or relevant observation. Incidentally, it applies to Mr. Mills' portfolio as well: CICS and IMS for example. Or consider DB2: it runs on many systems, but the capabilities in the mainframe version differ from those versions for other platforms.

Mr. Mills seems to be saying something different: he seems to be implying, because BizTalk Server (as one example) runs only on Windows, then it can connect only to other Windows-based systems or applications. That is FALSE. The facts are: the vast majority of the over 7,000 BizTalk Server customers use the technology to connect with assets on UNIX, Linux and mainframe based systems: 92% perform heterogeneous platform integration. In fact, Microsoft has long offered a technology that does nothing but integrate with IBM's iSeries and zSeries technologies. (it accomplishes this via IBM's proprietary protocols, which Microsoft must license).

Claim: "Their perspective is how to make Windows environments connect, as long as you're using Microsoft technology. Our view is: how do you make every environment connect whether you are using Microsoft or anyone else's technology," Mills said.

Microsoft Fact Check: This is the continuation of Mr. Mills' previous thought. In virtually every enterprise above a certain size or age, the rule is heterogeneity in IT. Whether you're an international bank, a specialty manufacturer, or a chain of sushi restaurants, there's a myriad of information systems and applications you need to deal with, and better connections among those systems allows you to run your business better. That's what SOA is about, and that's what Microsoft's SOA platform infrastructure is designed to help with. Thus, FALSE.

Claim: Mills claimed there is a big difference between IBM and Microsoft's approaches, saying that, in contrast to Microsoft, IBM uses open standards for XML and web services.

Microsoft Fact Check: FALSE. Implying that Microsoft does not support standards like XML and WS-* is odd. This denies the reality of the past 7 years, during which Microsoft has repeatedly been recognized by independent analysts as leading the industry drive toward defining and implementing open protocol standards such as XML, and WS-*. It is also an attempt to revise history as Microsoft and IBM partnered on Web Services Standards in 1999 which led to the original specifications. Mr. Mills himself stood up with Bill Gates to talk about the two companies' collaboration on these standards. Moreover, Microsoft and IBM have continuously defined additional Web service specifications and publicly tested interoperability. Examples include WSDL, WS-Security, WS-ReliableMessaging, etc.

But let's talk specifics. Take one example: XML Serialization. XML Serialization has been part of the .NET Framework since v1.0. XML Serialization allows a developer to map between instances of objects in a program, and instances of XML documents, very simply. This is a key interop-enabling capability; it means, in part, that a .NET application running on Windows can very simply emit an XML instance document that can then be consumed by any other XML-capable application, running on any other platform. Or vice versa. And it's a foundation for other, higher-level interop capabilities: start with XML Serialization and add in message transport and tools, and you then can get Web services.

This XML support has continued through the versions of .NET across the years, and has been expanded significantly. WCF, shipped in .NET 3.0 in December 2006, added some new capabilities and more mature models – dealing with XML in .NET apps is now both easier and more flexible. The list of open standard protocols supported in WCF includes: HTTP1.1, XML, SOAP1.1, SOAP1.2, WS-Addressing, XOP, MTOM, WS-Security (including x.509, Kerberos, and SAML 1.1 token profiles), WS-Policy, WS-Trust, WS-Coordination, WS-AtomicTransaction, WS-SecureConversation, WSDL 1.1, WS-MetadataExchange, WS-Transfer. Looking forward, in the .NET Framework v3.5 (currently at beta 2), we've included support for REST-style web services, as well as internet syndication protocols like ATOM and RSS, and other protocols like JSON.

Microsoft does support optimized protocols and formats in WCF for Windows-to-Windows communication. IBM provides similar optimizations for their products, as do all SOA platforms.

Claim: Microsoft and IBM have tussled over XML standards.

Microsoft Fact Check: TRUE. But, like the observation that Windows is the OS that underlies Microsoft SOA infrastructure, this is not an interesting part of the story. The picture that is painted by the article would lead one to suspect that a tussle over standards is exclusionary or at least stalling productivity. Coexistence of multiple standards and encouraging market participation in standards evolution is paramount. The OOXML / ODF point in the article is like saying you won't be able to send digital pictures to your mom because there isn't a single standard for graphic presentation. Clearly there are multiple standards for digital images, gif, jpeg, png and so on - which has arguably helped drive utilization. The far more important point is implementation of multiple standards which Microsoft technology does.

OOXML and ODF are about documents. Discussion of documents needs to include all standards, many of which Microsoft supports and has lead. Examples include HTML, CSS, etc.

Claim: "The [Microsoft] MSDN mechanism is a lightweight messaging infrastructure in a message-based environment, whereas IBM delivers a fully functioning infrastructure," [Mr. Mills] said.

Microsoft Fact Check: FALSE, judging from the wide variety of customer case studies that describe how customers utilize .NET and the rest of the Microsoft platform to broadly exploit the benefits of SOA. Microsoft customers use the Microsoft SOA infrastructure to run the core information systems that power their businesses. IBM's Web sites discusses the "entry points" to SOA. Microsoft has equivalent products in Microsoft Office Sharepoint, IIS/ASP.NET, BizTalk Server, WCF, Visual Studio and adaptors for existing applications.

As a side note, MSDN is a developer-outreach program, including a website, a software subscription and licensing offering, a magazine, and more. It's not directly related to SOA infrastructure. IBM has developerWorks, which is similar in intent.

In Closing

Do you want to know just how serious we are about Interop and Performance? Take a look at our .NET Stock Trader application which we modeled after IBM's Trade 6.1 performance application. We've demonstrated our ability to interoperate with applications that run on other platforms including IBM WebSphere applications running on Windows, Linux, or Unix™ . Don't miss this part: the .NET application duplicates the function of the Websphere app, but with far better performance.

[This article was drafted by Dino Chiesa and Steven Martin. It is being posted on both of our respective blogs.]

Lessons learned using RSS with .NET 2.0: Simplicity and Speed

DotNetInterop — Tue, 09 Jan 2007 01:52:00 GMT

RSS, .NET 2.0, and Interop

For many people, when they think of Interop with respect to .NET development, they think, first and foremost, Web Services. This is good as far as it goes but...Web services is neither necessary nor sufficient for interop in many cases. RSS is a great example of an XML document protocol that is very useful for interop - in practice, interop between RSS Readers, RSS producers, aggregators, and so on. The document format is RSS, the protocol over which that document is exchanged is often HTTP - the web protocol - but of course it could be *anything*. Any protocol. How does .NET 2.0 support RSS for Interop?

A Digression - IE7 and RSS

I installed IE7 a while back, and I am pretty happy about the RSS support built-in to it. Navigate to an RSS feed and you get a reasonable user-friendly display of the feed. It's not a feed reader or rss manager, but it's nice to not see the angle brackets in the browser, when I just want to browse an RSS doc.

Separately, I wanted an app that could dynamically create a digest of a website - this is a sort of tactical app I needed for something at work. Obviously, it's gotta be RSS or ATOM. I wanted build the app in .NET, and it will run as a web app. This means ASP.NET.

How can I create an RSS doc from within .NET? I know about the RSS.NET project on sourceforge, and I have actually used that DLL in some other projects - RSS.NET was integrated into the Club Web Starter Kit that was created as a usable example of what you could do with ASP.NET 2.0. It was good for what it did, but I had a few problems (this was a while ago) with particular variants of RSS. I made some changes but never bothered to raise a bug on the sourceforce project, basically it was more effort than I was signed up for. In any case it worked, but I was a bit shy of the license, and so on.

Now I Was doing some more RSS stuff, and with my bad developer habits , I ignored what already existed and set off to build my own RSS library. After much effort, many errors, and... oh, wait. Hold on a second. It wasn't much effort after all, and there were no errors and backtracking. Basically it took me 10 minutes to build an RSS library in .NET, and it was very straightforward. Here's the resulting class diagram from Visual Studio 2005:

The process was pretty simple and the same approach should work with any XML dialect. How did I do it?

The tools in the .NET SDK make this simple

The first thing I did was grab a sample RSS document. Then I ran it through the xsd.exe tool, which is part of the .NET 2.0 SDK. The result of that was an XSD document, describing the schema for RSS. Then I ran that through xsd.exe , and the output of that was a .cs source file, modelling the RSS document.

Aside: Lots of developers have this idea that the output of a tool, any tool, is sacrosanct, and cannot be changed. As if the tool knows better than you, what you need. I don't subscribe to that philosophy. The output of one tool is just the input to the next tool, in my opinion.

I took the .cs source file that was kindly generated for me by xsd.exe, and doctored it up, added a few helper methods to the generated classes, tweaked the names of the classes and so on, and I had myself a simple RSS library, perfectly suited to my purposes. (Note: the diagram above is from Visual Studio. It essentially is a graphcial model of the generated class. I didn't actually use any premium feature in Visual Studio to generate the class. I used only the .NET SDK Tools. VS just generated the pretty picture.)

Honestly**, the entire effort on this was about 10 minutes. As I prototyped the app, I saw what I needed and what was missing from the RSS object model, and I tweaked it a little as I went along. A few iterations and the project was done. Boom. I didn't need to examine the license for a third-party tool, I didn't need to understand the model for the third party code. It was small and simple (Really Simple, you might say!). If you want to see the source, see the link below.

[**Honestly, don't you hate when people say, "Honestly,..." As if most of the time they're not being honest, but this time they really are....]

That's what I love about .NET development: Things are surprisingly easy to accomplish. This approach should work with any XML dialect. I am sure there are billions and billions out there, and most of them, if they are simple enough, should be workable with this approach.

What I did here was generate a library that allows any .NET application to produce an RSS document from any content type it can access. I could also have extended this so that it could consume RSS streams, but that was out of scope for my project, so I didn't do it. You should be able to do something similar for any XML Schema, including internal-only schema that you use only for exchanging documents inside the walls of your corporation or organization.

Happy angle brackets to you!