Computer and Internet Technology: 11/01/2005

Switching from MSN space to Blogger.com
After trying new set of blogging and picture sharing tools, including blogger.com, blogger for word, hello+picasa, flickr. I decided to quit the domain of Microsoft blogging field, follow google for the following reasons:

blogger has more flexible template definition tools, it gives you ability to manage you site appearance in html code level

blogger from word really improve my productivity of blogging, in contract to the old msn space’s online editing or email publishing. Now you can take advantage of word’s powerful editing capability

hello+picasa indeed brings picture uploading and sharing process into a new era, instead of spaces’s loose resolution picture sharing.

xml communication indicates the Web 2.0’s coming, you can use a bunch of tools not matter you are online, or in word, or hello, or any other xml-aware tools

personal belief that google’s fasting growing and effect of rapid evolution process including new technology implementation and fresh tools

etc.

Here is the process of my blogging history.

博客.CN 2004/4 – 2005/4

MSN Space 2005/7/2 – 2005/11/23

Blogger.com 2005/11/23 - Now

Now this is my newly fresh blogger coming from blogger.com. http://linuszhu.blogspot.com/

My current set of tools

Blogger.comhttp://linuszhu.blogspot.com/

hello+picasaaccount : polease

MSN Messengeraccount : linjohnston@hotmail.com

Skypeaccount : linuszhu

Email linuszhu@gmail.com

Flickrhttp://www.flickr.com/photos/polease/account : linuszhus@yahoo.com.cn

FolderShareaccount : linuszhu

Live.comaccount : linuszhu

My personal link

using to post my personal diary and featured picture

using to organize and share my photo album
using to organize and share my personal favorate link

DataSet as webservice passing object tuning
Linus
2005-11-20

Background
SmartClient technology now is very common used in the new era of SOA infrastructure, as publishing a webservice to the whole world, getting rid of bothering issue like firewall, has become a piece of cake.
In .net, Microsoft gives birth of dataset, originated from recordset, which struts its stuff in the world of data binding. DataSet, usually represents a portion of relation table data, could contain a considerable amount of data returned from database. When passing this kind of large object by web service, due to the inborn issue of http communication regarding to TCP/IP (the performance issue), it would bring a headache for your app’s performance, especially critical in a slow network environment.
Practices

.net dataset serialization

  I was planning to using binary serialization instead of xml serialation after I found out that most of SOAP package data are xml tags. But things are not that easy.
  In .net framework 1.1, drilling down the implementation code, you could discover that, the framework would use XmlSerialization, even if you choose BinaryFormatter, to serialize the dataset. Let’s check it out as the following.
void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context)
{
      string text1 = this.GetXmlSchemaForRemoting(null);
      string text2 = null;
      info.AddValue("XmlSchema", text1);
      StringBuilder builder1 = new StringBuilder(this.EstimatedXmlStringSize() * 2);
      StringWriter writer1 = new StringWriter(builder1);
      XmlTextWriter writer2 = new XmlTextWriter(writer1);
      this.WriteXml(writer2, XmlWriteMode.DiffGram);
      text2 = writer1.ToString();
      info.AddValue("XmlDiffGram", text2);
}
  You can see that it would append xml schema, following by the dataset xml data. When the dataset is a pretty complex one, I found out that the schema would result in 15K bytes transportation.
  Microsoft has already noticed this problem. In .net framework 2.0, binary serialization is pretty small than the old version, because it does NOT use xml serialization as binary serialization again.
private void SerializeDataSet(SerializationInfo info, StreamingContext context, SerializationFormat remotingFormat)
{
      info.AddValue("DataSet.RemotingVersion", new Version(2, 0, 1));
      info.AddValue("DataSet.RemotingFormat", remotingFormat);
      info.AddValue("SchemaSerializationMode.DataSet", this.SchemaSerializationMode);
      if (remotingFormat != SerializationFormat.Xml)
      {
           …
            for (int num1 = 0; num1 < this.Tables.Count; num1++)
            {
                  this.Tables[num1].SerializeTableData(info, context, num1);
            }
     …
      }
…
}
  Of course, I should try another way, because we are using .net framework 1.1. That results in the following tricky means.

Compressed webservice communication

In accident, I figured out, when I zipped my response data, it’s size would become about 7 times less than the original. So I start to put this method, what I called compressed webservice communication, into practice.

Change the WebService WebMethod a little bit, returning a string instead of DataSet

      [WebMethod]
public string GetInitializedTestObject()
{
      TestObject obj1 = new TestObject();
      StreamReader reader1 = File.OpenText(@"C:\Documents and Settings\zhuzhlin\Desktop\SmartClientTuning\SendReceiveData.xml");
      obj1.name = reader1.ReadToEnd();
      reader1.Close();
      string text1 = Data.GetXmlSerializedString(obj1);
      obj1.OrignalXmlSize = text1.Length;
      text1 = Data.Compress(text1);
      obj1.CompressedBase64Size = text1.Length;
      text1 = Data.GetXmlSerializedString(obj1);
      return Data.Compress(text1);
}

Change the client a little bit

public Fdms_webservice.TestObject GetRealInitializedTestObject()
{
      string text1 = this.GetInitializedTestObject();
      text1 = Data.Uncompress(text1);
      return (Fdms_webservice.TestObject) Data.GetXmlSerializedObject(typeof(Fdms_webservice.TestObject), text1);
}

  The result was astonishing, using Ethereal you would discover the data package dropped from 182K to 11K. And our result performance upgrades from 14seconds to 3 seconds average. Awesome!
(image placeholder)
Tools