Data compression in .NET

In .NET, developers often have to choose between 2 options for compression/decompression - GZipStream and DeflateStream. What's interesting to note is that GZip uses the same 'deflate' algorithm as DeflateStream; but in addition also supports CRC checks and has additional headers to store metadata such as version nos, original file name, timestamps, etc.

So GZip is actually a data format and multiple files can be compressed into a single archive. You can open a file written to by the GZipStream using a GZip decompression utility such as WinRAR on Windows, gunzip on Linux, etc.

Sample example code can be found at MSDN.  There is also a sample solution that allows working with multiple files using GZip compression. Both these classes only support max 4GB as the stream length.

Interoperability when using datasets in .NET webservices

Datasets are powerful data containers that are very popular in the .NET world. Quite often, a lot of .NET webservices return datasets in their web methods. This is ok, as long as we are sure that all the clients are also on the .NET platform. 

But if we want our services to be interoperable with other platforms (e.g. Java), then passing datasets back to webservice clients would not work. This is because a dataset is a generic container and is populated at runtime with data. Hence at design time, it is not possible to define the dataset datatype with a schema. Also when a dataset is serialized to XML, then the default .NET SOAP serializer adds .NET specific attributes to the XML schema. e.g. isDataset=true, Diffgram, etc.

Typed datasets do have a schema backing them, but here again there is a hack required to make typed dataset accessible to a Java program. The hack is to return a xml string or a XML Node instead of the typed dataset. We would also have to change the autogenerated WSDL and add the typed dataset schema to it. A lot of trouble for using datasets in a heterogenous environment :( 

For hassle free interop, the best option is to go for pure schema driven complex types that can be mapped to any language.

More information is available at the following links:

http://msdn.microsoft.com/en-us/magazine/cc188755.aspx

http://msdn.microsoft.com/en-us/library/ms998428.aspx

http://www.cnblogs.com/rickel/articles/157935.html

XML serialization tips in .NET

Today, my team ran across a strange issue. Some of the properties on a .NET class were not getting serialized to XML when used in webservices. There was no error message or any other warning. 

Closer examination revealed that the properties not getting serialized were 'read-only' properties; i.e. they had getters but no setters. The default XML Serializer in .NET calls the property getters/setters and hence if a read-only property is present, then it is not serialized.

Once we added setters to the properties, XML serialization worked fine.

There is another option. We can implement the IXmlSerializable interface and write custom serialization code. But this could be very tedious. 

Java to .NET conversion tools

Today one of our teams was looking for a Java to .NET conversion tool. They had developed resuable components in Java and the client wanted similar components in their .NET environment.

Microsoft used to ship a module called JLCA (Java Language Conversion Assistant) that enables us to covert Java code to .NET code. This tool was shipped as part of VS 2005, but unfortunately is no longer shipped with VS 2008. Please read Microsoft's statement here regarding JLCA. 

I had a quick look at the tool by launching it from VS 2005 and selecting a few Java util libraries. The results looked good, but we need to understand that 100% conversion is not possible. The tool puts in a lot of comments in the generated .NET code, so all errors and warning are maked in the generated code. Also a cool HTML report is generated that mentions the errors and warnings. I could find tons of errros/warnings, but most of them fell into expected categories such as no direct mapping between Java and .Net classses, etc.

ArtinSoft offers an enhanced version of the JLCA tool called JLCA Companion. I have not evaluated this, but the documentations states interesting features for customization.

To summarize, I believe such migration tools are useful to jumpstart the process and have a foundation ready to work on.

Async calls in Java and .NET webservices

Over the past few weeks, the Architecture Support Group that I head at my organization, received quite a few queries on making asynchronous web service calls in a SOA environment. So decided to blog about the various options at hand.

To make asych webservice calls in .NET, the following programming models are available. Please visit the links for furthur information.

1. Using Asychronous Callback delegates.  

2. Using Event Based Asych methods

3. Fire and Forget mechanism: Here we can decorate the server side webmethod with the 'OneWay' attribute.

On the Java side, the popular Axis-2 framework supports asych web services calls out of the box, by generating call back handlers in the webservice proxy.

The WS-Addressing specification is also trying to bring in a standard for defining different MEP (Message Exchange Patterns).