Dotmad.net

I have recently been to an Israeli user group meeting in which iDesign’s Juval Lowy gave a lecture about the new Azure .Net Service Bus for web services written in WCF.

Basically a service bus is a router, similar to the one you use in your office network. Instead of needing to update the configuration for multiple clients each time a service they are connected to is moved to a new location or changes channel, all clients/services connect to a central hub. In this case the service bus is located online, somewhere on Microsoft servers.

Here is what the meeting’s page says about the lecture:

The .NET services bus is part of the new Microsoft Cloud Computing Windows Azure initiative, and arguably, it is the most accessible, ready to use, powerful, and needed piece. The service bus allows clients to connects to services across any machine, network, firewall, NAT, routers, load balancers, virtualization, IP and DNS as if they were part of the same local network, and doing all that without compromising on the programming model or security. The service bus also supports callbacks, event publishing, authentication and authorization and doing all that in a WCF-friendly manner. This session will present the service bus programming model, how to configure and administer service bus solutions, working with the dedicated relay bindings including the available communication modes, relying on authentication in the cloud for local services and the various authentication options, and how to provide for end-to-end security through the relay service. You will also see some advanced WCF programming techniques, original helper classes, productivity-enhancing utilities and tools, as well as discussion of design best practices and pitfalls.

Although Juval clearly know a lot on the subject, and apparently is currently doing a tour lecture on the subject (at least in Israel and Belgium), I have to say the talk was not very interesting for experienced WCF developers. This is due to the fact the interface is almost identical to that of a simple WCF service, therefor I kept getting a feeling of “been there, done that“. It’s very easy to work the .NET service bus.

The .NET service bus supports both TCP/IP and HTTP based connections (highlight of the lecture: “to add WS support just add an ass“), and allows both connectivity through the cloud or P2P (after negotiation). There is a limited usage to SSL transport level security, something that alarms me a bit, as this is the best performance/security ratio option in WCF.

I do have to wonder regarding the usability of this platform. Many companies I know moved to SOA architecture, splitting central servers to many services. Such systems need a service bus residing inside the local network due to two reasons:

1. Local network is more secure. Although Mr. Lowy waved his hands and replied “message level security is NP complete” to a question on the subject, I doubt IT managers or security officers in large firms would accept that.
2. Local network is faster. Although a large downwards bandwidth is easily obtained, for a true 2 way communication you need a decent outgoing bandwidth (unlike ADSL lines, for example), and that’s not cheap.

There are local alternatives, both commercial (Microsoft Biztalk server) and open source (Udi Dahan’s NServiceBus).

I guess only time will tell if this new technology is successful.

After creating a custom UDP mulitcast channel using WCF I ran some tests. I used this sample data contract class:

string Name
string Description
ushort Id
double X
double Y
double VX
double VY
uint Flags
DateTime CreatedTime
DateTime UpdateTime

Benchmark Results:

• Max amount of sent objects per second using 100mbit hub (using Intel 3Ghz HT CPU - not dual core): 46000
• CPU load during peak sending - 15-25%
• Effect of zip encoding - 50% less bandwidth with random values (probably 60-70% reduction in a real-world scenario)
• Sending 10000 objects per second - no significant CPU load (3-5% for both apps), GC load - less than 0.5%

I recently needed to build a WCF UDP application as a proof of concept.

Sadly UDP is not among the channels bundled with the WCF, so I needed to put up something myself:

• Downloaded the WCF technology samples, containing a UDP transport demo (there used to be a sample at the netfx3 site, but it’s long-gone)
• Copied the UDP transport sample project (from the folder \Extensibility\Transport\Udp\Cs\UdpTransport) into my solution
• Added the extensions section to the config file to add the UDP support (config file coming up soon)
• Added multicast=”true” switch to the binding section
• The address prefix is hardcoded in the UdpChannelHelpers.cs file, so if you like something other than “soap.udp” you need to edit the “Scheme” constant.
• Since UDP is limited by a 64kb packet size, you may also want to use the GZipEncoder (found in \Extensibility\MessageEncoder\Compression\CS\GZipEncoder)

You need to remember that since this is multicast, the client is the one doing the transmitting while the service is a only a passive listener.

Client configuration:

<configuration>    <system.serviceModel>

      <extensions>        <bindingElementExtensions>          <add name="udpTransport" type="Microsoft.ServiceModel.Samples.UdpTransportElement, UdpTransport" />        </bindingElementExtensions>        <bindingExtensions>          <add name="sampleProfileUdpBinding" type="Microsoft.ServiceModel.Samples.SampleProfileUdpBindingCollectionElement, UdpTransport" />        </bindingExtensions>      </extensions>

      <client>        <endpoint address="net.udp://225.225.0.1:2222/Observer/"          binding="customBinding"          bindingConfiguration="DatagramServer" contract="DataContracts.IObserver"          name="ClientService" />      </client>

      <bindings>        <customBinding>          <binding name="DatagramServer">            <binaryMessageEncoding></binaryMessageEncoding>            <udpTransport multicast="true" />          </binding>        </customBinding>      </bindings>

    </system.serviceModel></configuration>

Service configuration:

<configuration>    <system.serviceModel>

      <extensions>        <bindingElementExtensions>          <add name="udpTransport" type="Microsoft.ServiceModel.Samples.UdpTransportElement, UdpTransport" />        </bindingElementExtensions>        <bindingExtensions>          <add name="sampleProfileUdpBinding" type="Microsoft.ServiceModel.Samples.SampleProfileUdpBindingCollectionElement, UdpTransport" />        </bindingExtensions>      </extensions>

      <services>            <service name="ObserverService.Observer">              <endpoint address="net.udp://225.225.0.1:2222/Observer/"                   binding="customBinding"                  bindingConfiguration="DatagramServer"                  contract="DataContracts.IObserver" />            </service>       </services>      <bindings>        <customBinding>          <binding name="DatagramServer">            <binaryMessageEncoding></binaryMessageEncoding>            <udpTransport multicast="true" />          </binding>        </customBinding>      </bindings>    </system.serviceModel>

</configuration>

One of the new and very annoying feature of Visual Studio 2008 is the WCF service host:

Windows Communication Foundation (WCF) Service Host (WcfSvcHost.exe) allows you to launch the Visual Studio debugger (F5) to automatically host and test a service you have implemented. The tool is integrated into Visual Studio through the WCF Service template and is invoked when you start to debug your project.

Sounds like a useful tool, right?

Well, if you don’t need this functionality, especially if you are used to VS 2005 WCF development, this can be incredibly annoying, more so since you can’t disable the darn thing.

Well, Dr. Nick comes to the rescue:

Simply look for this GUID and remove it from your csproj file (don’t forget to remove left over semicolon):

{3D9AD99F-2412-4246-B90B-4EAA41C64699}

Apparently the upcoming service pack for Visual Studio 2008 should include an easier way to disable the service host, so hopefully this solution is temporary.

This is something I wrote a while ago to allow easy way to serialize/deserialize various objects to and from XML by creating an adapter around the XmlSerializer class.
Since I don’t know how this XML is going to be used this class stores it inside a string.

Serialize usage:
string s = SimpleSerializer.Instance.ToString(myObject);
XmlDocument xDoc = new XmlDocument();
xDoc.LoadXml(s);

Deserialize:
MyClass obj = SimpleSerializer.Instance.FromString(xDoc.OuterXML);

    /// <summary>    /// Objects serializer/deserializer    /// </summary>    public class SimpleSerializer    {        private static readonly SimpleSerializer instance = new SimpleSerializer(); //Singleton

        /// <summary>        /// Gets the class's instance.        /// </summary>        /// <value>The instance.</value>        public static SimpleSerializer Instance        {            get { return instance; }        }

        /// <summary>        /// Private constructor - prevents tempering with the singleton pattern        /// </summary>        private SimpleSerializer()        {        }

        static SimpleSerializer()        {        }

        /// <summary>        /// Converts an object to it's XML represntation        /// </summary>        /// <param name="message">The source object</param>        /// <returns>XML represntation</returns>        public string ToString(object message)        {            System.Xml.Serialization.XmlSerializer serializer = new System.Xml.Serialization.XmlSerializer(message.GetType());            using (System.IO.StringWriter sw = new System.IO.StringWriter())            {                serializer.Serialize(sw, message);                return sw.ToString();            }        }

        /// <summary>        /// Converts an XML to an object        /// </summary>        /// <param name="message">The XML</param>        /// <param name="type">The expected result class</param>        /// <returns>A new object deserialized from the XML</returns>        public object FromString(string message, Type type)        {            using (System.IO.StringReader sr = new System.IO.StringReader(message))            {                System.Xml.Serialization.XmlSerializer serializer = new System.Xml.Serialization.XmlSerializer(type);                return serializer.Deserialize(sr);            }        }

        /// <summary>        /// Converts an XML to an object        /// </summary>        /// <param name="message">The XML</param>        /// <typeparam name="T">The expected result class</typeparam>        /// <returns>A new object deserialized from the XML</returns>        public T FromString<T>(string message) where T: new()        {            using (System.IO.StringReader sr = new System.IO.StringReader(message))            {                System.Xml.Serialization.XmlSerializer serializer = new System.Xml.Serialization.XmlSerializer(typeof(T));                return (T)serializer.Deserialize(sr);            }        }

    } 

I have written before a short comparison between “old” and newer technologies, but at the beginning of that post I state that part of the choice of a new technology is the market trend towards that technology.
After reading Justin’s post showing that moving to ASP.NET is beneficiary because it’s becoming a prominent technology I decided to implement his research methods (using Google) on different technologies.

I began by searching for file types

However, this reflects only on files shared on the web, and since JAVA is a web technology (unlike Delphi) the results don’t say much.

But Google trends provides a clearer picture - while C# remains stable, other programming languages are on the decline:

Focusing on the .Net world, you can clearly see new technologies are dominant in Google searches:

WPF vs. Winforms

WCF vs. Remoting

The rise of .Net Framework 3.0 technologies

With Silverlight being the “Hot New Thing” (maybe because it’s a web-based technology)

So maybe choosing a new technology is a logical move even if it doesn’t offer a significant technological advantage - since keeping older technologies means you are working against the market trend.

So consider switching from Winforms to WPF, from various communication technologies to WCF and from VS 2003 or 2005 to VS 2008 - in the long run the market will force you to do it anyway, either through the job market or through customers demands.

We all know about the “cool new kids in town”, meaning new technologies all developers want to use. Offer a developer two positions:

1. Programming with C# 1.1
2. Programming with WPF and C# 3.5

What do you think most developers will choose?

However, there is the question of an existing project, written in an “uncool” technology.
In my experience developers tend to push towards using newer technologies, but how do you convince the people in charge?

Here are my thoughts on the subject:

Framework 2.0 vs. 1.1
Advantages: Performance boost if you are using ArrayLists with value types in them (when you switch to generic Lists)
Disadvantages: Incompatibility issues requiring code changes (should be very minor)

Framework 3.5 vs. 2.0
Advantages: Using Linq for new complex data access and query modules, otherwise I’m unsure
Disadvantages: Same as switching between 1.1 and 2.0

WCF vs. Various communication technologies
Advantages: Much easier to configure and deploy, can drastically change the communication method without any code changes
Disadvantages: Not applicable when you do most of the communication in a non-.Net world if you remote points are not using web services protocols (example: communication with hardware sensors)

Workflow foundation
Advantages: Easier to manage complex workflows. Enables user modification of workflows.
Disadvantages: If an existing workflow code is already written - major code rewrite.

WPF vs. Winforms (with CGI+)
Advantages: Creating easily resizable forms due to vector graphics use. Customize look & feel in ways which are almost impossible to duplicate using winforms. Easier interaction between UI/graphics designers and developers.
Disadvantages: Will require serious code rewrite. Performance issues still exist (I have yet to witness a professional map engine based on WPF)

Team system vs. various source control / task management systems
Advantages: I have used SourceSafe, PVCS and Rational ClearCase/ClearQuest, and to this date I think VSTS is better is terms of performance, ease of use and customizability, especially when you need to integrate source control and task management.
Disadvantages: Requires Windows - how do you use VSTS to manage C++ code in a Unix/Linux environment?