A look back in interop
 |
We had a conversation with a long-time software hand the other day, one whose company had created a means to convert and run Java within .NET. This individual told us of his surprise at the developer community’s reaction to this software when first released. One might summarize the reaction as a good dose of vitriol and some asides to the effect that, if the Creator meant for Java to run within .NET.. well, that actually would have been a mistake on His part. In other words, let’s not mix things.
Ted Neward’s post on this Interoperability Blog have pointed to the need to look afresh and ‘leave politics’ at the door when considering apps that integrate Java and .NET functions. Looking back, some of Neward’s words, from a 2004 whitepaper on the topic, which follow, still ring true. And they provide a good entry into what TheServerSide Interoperability Blog seeks to be about. – J. Vaughan, Site Editor, TheServerSide.NET |
Making two platforms interact is at once a simple and difficult problem. Simple, in that it’s a fairly closed-requirements solution: if I can work out a few technical details, interaction is achieved. It’s also fairly easy to achieve success–if they can talk, you did it, if not, there’s still work to go. In fact, once you’ve worked out low-level issues like byte order, file/data format, and hardware compatibility, basic interaction between any two platforms is pretty straightforward. (As a matter of fact on this basis was the Internet built.)
* * *Historically, we’ve preferred “n”-tier systems to client/server 2-tier ones, because of the increased scalability intrinsic to “n”-tier systems. An “n”-tier system can scale to much higher user counts, due (among other things) to the shared database connections from a central middle tier to which clients connect. We also prefer the “n”-tier approach because it tends to allow for better separation of responsibilities in code: presentation-layer code goes on the client tier, business logic goes on the middle tier, and data-access code (largely represented by SQL) goes on the resource tiers either on or behind the middle tier machines. 3-tiers, 3 layers, but not always mapped one-to-one.
Drawing a distinction between the tiers and the layers is necessary for good interoperability between the platforms, because interoperability across layers is going to necessitate very different decisions than interoperability within layers. For example, if you have a Windows Forms .NET application that wants to display a Swing applications as a child window, very different decisions are in order than if you want that same Windows Forms applications to talk to a J2EE back end. Web services might suffice for the second requirement; it’ll be an unmitigated disaster if you use Web services for the first.
* * *So often, demos done on the expo show floor clearly prove that the product knows how to talk to the same vendor’s product on the other side of the wire, but rarely if ever demonstrates working with another vendor’s product. So, for example, an ASMX Web Methods Web service can easily declare itself as returning a Hashtable, for example, but once marshaled and sent across the wire, what format should it resemble in the J2EE space? While Java certainly has its own implementation of Hashtable, there’s no love lost between them in implementation details. As a result, it’s a fair bet (barring special code to the contrary), the .NET Hashtable will get rendered into a custom data format that has little to no bearing on the .NET Hashtable in widespread use.
For these reasons, just as with data exchange using XSD, when writing WSDL-based services, always start with the “parts in the middle”: in this case, the WSDL.
What do you think? Have things changed over the years? Are there places where both of these major platforms should be used within a single application?
Interoerability White Paper - 2004
Leave a Reply