Blogging the Interop blogs -Framework versions; APIs evolve; Jagged arrays

. NET Framework version issues
Recently, U.K. developer Chris Alcock wrote about good API Design. A key point: you should never make changes to the API that will break your client’s code. An example cited: throwing exceptions based on values previously considered ok.

Even more recently, Alcock came across the precise problem. It occurred while installing  the .NET 2.0 Runtime on a server that in turn runs a number of .NET 1.1 applications and a number of classic ASP applications consuming COM components written in .NET 1.1.

Investigation revealed that instead of using the .NET 1.1 version of System.Web both CScript and the IIS DLLHost were loading the .NET 2.0 version. Loading the source code for the component into Visual Studio 2005 and attempting to compile and run a simple test application revealed a Null Reference Exception from within the framework.

“A code change to use a call to System.Web.HttpRuntime.Cache to obtain the cache instance fixed our problem, and a quick rebuild of the component against .NET 2 and redeploy to the server and we were back up and running,” wrote Alcock.

Commenting on Alcock’s blog, well-known developer-blogger Scott Hanselman noted a way to force IIS to use a specific version of the framework.

When APIs Evolve or- How I Lost My Lunchtime -
Good API design –
How to Force IIS to Load a Certain CLR -

History of Office XML formats
Brian Jones has created a timeline depicting the history of Office XML formats, beginning in 1998. He is open to additions. Take a look back in formats.

History of Office XML formats - MSDN Blog

Known-issue in WCF bungles bindings in WSDL
Ted Neward starts a trouble ticket rolling on Apache archives.

Working with WCF - Apache archives

Jagged arrays, and empty too
“Tiberiu” developed a Java web service which contains a simple function - the function returns a double-dimensional array of integers. The next step was to create a simple .NET web client which calls the function. But, when running a WSDL utility (generated by an Eclipse bottom-up web service wizard), “the result is returned as an empty jagged array”. Any vet SOAP serializers out there that can help?

WSDL question - Tech-Archive

Mainsoft: Interop mainstay

By Jack Vaughan 

Mainsoft Corp. is one of a few companies that have made their mark in cross-platform development tools. It has been prominent in a field others have eschewed, going back to the days before Java, when the ‘war’ was between Unix and Windows.

Over the years Mainsoft has forged deals, sometimes controversial, to use Microsoft source code in order to provide broader platform support. In the fall, Mainsoft announced services and support for IBM WebSphere Everyplace Deployment 6.0, so that one can run .NET Web applications natively on WebSphere software running on a Linux desktop.

As more companies find a need to support both Java and .NET applications, Mainsoft has expanded its product portfolio to include various means of J2EE and .NET interoperation.

Early last year, the company forged a deal with Azul Compute Appliances to enable shops to run .NET and Java applications in the same server pool. Can it be said that the data center is driving many interoperability scenarios today?

While compute appliances are far from mainstream, it does seem that bigger companies are pushing to consolidate server operations, and these companies tend to have a mix of platforms supported. Linux too, is firmly entrenched now in many data centers. Microsoft itself may be paying attention now. Witness the alliance based around SUSE Linux that Microsoft recently announced with Novell.

Around the time of Mainsoft’s pact with Azul, we spoke with Yaacov Cohen, president and CEO of Mainsoft. He said Mainsoft’s path was to solve interoperability issues at compile time. .NET developers work as they are accustomed to; at compilation, that code is converted into Java byte code. Will the day come when creating a .NET app will not automatically mean deploying to a Windows server? Cohen and others think so.

Related: Hints and Tips for Effective Porting - Mainsoft Site

SOAP in/out variables bring memories of C-style buffers

SBalmos By Scott Balmos [posted by Jack Vaughan]
About a month ago I happened to be playing around with some parts of SOAP I hadn’t really gotten into much. At the time, I tried out in/out variables. Support for in/out variables, at the time I looked, was still somewhat iffy. And it occurred to me that the idea of in/out variables seemed to go against traditional object->method() type OO programming that most SOAP implementations seem to embody. In a way, it reminded me a lot of the original type of OO in pure C, where buffer references were passed around in parameters.

Personally, I can’t think of a situation right now where I would actively use in/out variables. I’d be more inclined to stick with the SOAP ideology of a “message document transfer”, and simply create a slightly more complex response message (which, in turn, would translate to a response data type class that has one or two more fields to it).

This would seem to be easier on the brain than documenting that various return types could possibly have data changed in them upon return. Look at JAX-WS as it is, for instance. Instead of calling a SOAP endpoint with data types, you’d potentially have to use the Holder class, access that Holder’s properties to get to the data, etc etc etc. Is that really so much simpler than simply creating another field in the response complexElement? Okay, again, maybe so for those people writing in pure C, who are more than used to this form of object passing. But as it currently stands, Java and .Net are the two main drivers for SOAP usage.

And their programming paradigms are of the Smalltalk message-passing OO style, not the hybrid style where parameter values are different after a method call than they were beforehand.

One possibility is if some enterprising DB vendor decided to meld XML data return from the DB engine along with stored procedures that use in/out-type parameters along with a simple SOAP stack in the DB engine.

Then SOAP could be used to initiate those stored procedures, bypassing SQL altogether (for better or worse).

I’d be interested to hear back how you’ve used in/out SOAP variables in your projects so far, if you’ve used them at all. “Remember, I’m pullin’ for ya… We’re all in this together.”

A Rant of Sorts on Multiple .Net Web References

Written by Scott Balmos [Posted by Jack Vaughan]
I’ve got to admit, Visual Studio 2005 is a nice IDE. But when it comes to working with complex SOAP-based applications which have multiple endpoints and shared core, it can be a downright pain. I’m specifically referring to the Web References system, which transparently manages the annoyance of generating type stub and proxy classes from a WSDL file. It is, unfortunately, another classic case of Microsoft’s thought process behind trying to help developers work more efficiently - the common cases are very easy, but the hard things are very hard.

When it comes to Web Services, more and more systems are becoming increasingly complex. Many of them offer multiple endpoints - commonly one per major sub-application - while sharing a common core endpoint for initial authentication, session management, etc. Likewise, these endpoints share a common set of core datatypes, again usually a User, Session, and other such types. But trying to use these complex endpoints with Visual Studio is a downright pain. The Web References function insists on creating separate .Net namespaces for each different endpoint, even if the WSDL files for the two endpoints share a common XSD file that defines the shared core datatypes. Consequently, .Net refuses to acknowledge that a User or Session object retrieved from the core authentication endpoint really is the same User object that is supposed to be passed as a parameter in the billing, or personnel management, or other such sub-application endpoint.

No true explanation, nor any true answer to this dilemma has been given. The best I’ve seen are some people succumbing to the pain of manually changing the namespaces around in the auto-generated stub files. But that fix is short-lived, as the stub files are regenerated (separate namespaces and all) the next time the Web Reference is updated - a major pain for early-access developers to a web service whose WSDL file is still possibly in flux.

I don’t know about you, but I tend to see this as more and more of a thorn in the side of Visual Studio (and, by inference, .Net) developers as more complex SOAP services are built. For as much as Microsoft is trumpeting XML this and Web Services that, to believe that the Visual Studio and .Net groups didn’t seriously consider the use case of a complex service having multiple service endpoints is frustrating at best.

As I constantly continue building my one major JEE 5-based system (12 sub-applications and SOAP endpoints, with probably over 400 SOAP methods defined across those endpoints), and writing test SOAP clients in C#, I know I’ll be constantly bitten hard by this oversight. I’ll keep you updated if I find any more permanent answer, and let me know if you know of anything better.

I also, of course, welcome any vague ideas you may have for future blog entries. And I am not limited to SOAP/XML only, or specifically .Net and J2EE interoperability. In the coming weeks, I’ll be commenting on using J2EE systems with PHP, Ruby, and various other systems.

I’ll close off my blog entry with one of my favorite, and most poignant, lines from The Red Green Show (for you Canadians and Americans that watch PBS): “Remember, I’m pullin’ for ya… We’re all in this together”.