Websphere and .NET Interoperability Redbook from IBM: Be Careful!
WebSphere and .NET Interoperability Redbook - be careful
This Redbook from IBM, entitled "IBM WebSphere and Microsoft .NET Interoperability", was published in July 2006. I don't know where I was when it was published, but I missed it. Just getting around to looking at this document now. This is a brief editorial review.
First Things First
My mama always told me, start with the positives. here goes: I love the topic. This is a worthy topic as readers of this blog will probably agree. Today's enterprise demands more and better connections between disparate systems. Connecting .NET to WebSphere is one of the primary topic requests we get.
Beyond that, the material appears to be broad and pretty comprehensive. IBM's Redbook process seems to generate fairly large volumes, regardless of topic. This one is 418 pages. Whew! That could be good or bad, depending on your perspective.
What about the Not-so-Positives?
But it is not all dense material. For example, there is a section of 50-odd pages describing the ".NET platform" (sic). We at Microsoft do not call .NET a platform these days, we've sort of matured since the days of 2001 when .NET was everything and anything. These days we say that .NET is ingredient technology that connects people, information and devices. More specifically, if you want to talk about the .NET Framework, we say that
The Microsoft .NET Framework 3.0, is the managed-code programming model for Windows.
The .NET Framework is not a platform by itself, but is part of Windows, which is "the Microsoft platform." The .NET Framework is best thought of as ingredient technology. I didn't really agree with most of the treatment of .NET in the IBM document, but that's not a surprise, is it? The redbook uses terminology which Microsoft launched, but has since stopped using. For example "The .NET Enterprise Servers". We don't talk about that any longer, and we were not using that as a brand in 2005 or 2006, presumably when this redbook was being written. But it is understandable that this book has that dated term in it.
Beyond the treatment of Microsoft technology, I also disagree with the philosophy of the book as well. It comes off as mostly talking about what is possible, when interconnecting stuff, rather than also taking a stronger stand on what approaches are recommended. In other words, I am looking for guidance on when to use the various options, and I want that guidance to be pretty well grounded in empirical data.
There is a section in the book dealing with component interoperability... The book distinguishes between component interop and webservices interop. I'll assume you all know what web services interop means. The Redbook implies that "Component interop" would include things like, the "IBM Interface Tool for Java", the IBM WebSphere ActiveX Bridge, IIOP.NET, J-Integra, JNBridge, and Janeva.
Furthermore, the book recommends that "component interop" be used when (a) tight integration is required between .NET and Websphere logic, (b) when Performance is a major concern, and /or (c) when stateful conversations or asynchronous interactions are required. I hate to be argumentative (actually my wife says I like to be argumentative, but let us not go there just now...), but I don't really agree with any of these reasons.
Now on justification #1 for selecting "component interoperability" - for me, it's just flat wrong. You don't want tight coupling between .NET and Websphere. You want loose coupling, that's what SOA and IT flexibility is all about, that's what companies want. Tight coupling is DCE, CORBA, and all the stuff that didn't work before. So... #1 is mostly invalid as a justification, by definition.
The #2 reason to use component interop is performance. This is an easy argument to make, and so I see it often made, but I rarely see hard data. It is easy to say "in process integration will be faster" but how much faster? And just how fast does it need to be? And what is the real need here anyway - is it latency or throughput we are after? In most cases the goal is throughput, primarily - businesses want to scale. They don't need transactions to complete in 10 microseconds. They need to feel assured that they can run many many transactions all at once, even if each transaction might consume 1+ seconds of wall time. Throughput, not latency. And just how much of a throughput advantage does an in-process approach give us, over a webservices approach? The book doesn't say. It assumes "better perf" but doesn't quantify it. So the blanket statement that you should use component interop for performance reasons, is suspect. There's no data.
The final reason the book offers for using component interop between .NET and WebSphere is for stateful or asynchronous communication. Both of these are weak reasons, too, I think. Can you tell that I think the use of component interop between .NET and Websphere should be very judiciously applied, only when necessary and only when other, simpler and more mainstream (better supported by tools) approaches have been proven insufficient? Can you tell?
Moving on, I checked out the section on Web services interop. While the book makes a nice statement that "you should start with XSD and WSDL" - in effect, you should take a contract-first approach, the example the book provides DOES NOT take a contract-first approach. Instead the example says, take an EJB session bean and run the web services wizard on it. This is exactly the wrong approach to take when designing interop between Websphere and .NET. Below is the graphic the book uses to illustrate; I've doctored the graphic - can you tell which part I added?
After running through all these nits in the redbook that I got tired of picking, I stopped reading it. Bottom line: I think anyone who reads it should be careful with the guidance and information in this book.
That's all for now.
-Dino