Events in C# 4.0

Advertisements

Rx : Reactive Extensions for .Net and JavaScript.

Rx is a set of framework extensions to allow developers to easily do asynchronous programming via familiar interfaces. If you are familiar with LINQ and IEnumerable<T> and IEnumerator<T> you will instantly be able to grasp and use the new interfaces IObservable<T> and IObserver<T>. The enumerating interfaces allow you to PULL sequences of T from an interface in your code. The observing interfaces allow you to have sequences of T PUSHED to handlers in your code in response to asynchronous LINQ queries. Rx is implemented over the top of PFx (Parallel Framework extensions) so all the threading and concurrency is handled for you including synchronization contexts which is especially useful if you are programming UI. It is also particularly significant that the Rx extension methods include a FromEvent() method that allows you to attach handlers to a steam of events in a very fluid way.

If you want to know more watch the video on the bottom of this page where Rx author Erik Meijer explains it in 14 minutes.

If you want to see it in action have a look at this Channel9 video with Wes Dyer where he implements drag & drop from scratch using Rx in 6 minutes.

Also, checkout the Rx Team Blog for downloads, updates and samples.

Finally, back to Channel9 to look at RxJS for Reactive extensions for Java Script so the UI I mentioned above now includes web UI too. As Jeffrey Van Gogh says in the RxJS video, web programming is about “asynchronous stuff” but java script is an imperative language. It’s really hard to do good asynchronous stuff in java script. RxJS changes that it a big way.

Service (Bus) Browser

I’ve put together a little tool to help with some development work I am doing. While Azure and .NET Services are still in CTP the tooling is a bit limited so, what with necessity being the mother of invention and all that, I’ve spent an afternoon hacking together my Service(Bus)Browser.

Basically, all the endpoints you create in a .NET Services solution – routers, queues, relay endpoints etc – are all listed in the service registry which is exposed as an Atom feed at the base URL of your solution. So, if you create a solution called “MySolution”, your registry root is at https://mysolution.servicesbus.windows.net. Point your favourite web browser at it and you’ll see what I mean.

However, only endpoints whose discoverability policy is set to public will appear unless you also submit the correct credentials when requesting the Atom feed. Here’s an example :

<feed xmlns="http://www.w3.org/2005/Atom">
        <title type="text">Publicly Listed Services</title>
        <subtitle type="text">This is the list of publicly-listed services currently available</subtitle>
        <id>uuid:6bbbd412-81e8-4f30-8629-909d8175e05a;id=558</id>
        <updated>2009-08-05T21:08:29Z</updated>
        <generator>Microsoft .NET Services - Service Bus</generator>
        <entry>
            <id>uuid:f661ac5a-e633-46b7-9d2a-845676c92c82;id=43</id>
            <title type="text">rest</title>
            <updated>2009-08-07T23:06:20Z</updated>
            <link rel="alternate" href="https://mysolution.servicebus.windows.net/rest/"/>
            <link rel="self" href="https://mysolution.servicebus.windows.net/rest/"/>
        </entry>
        <entry>
            <id>uuid:6bbbd412-81e8-4f30-8629-909d8175e05a;id=559</id>
            <title type="text">testqueues</title>
            <updated>2009-08-05T21:08:29Z</updated>
            <link rel="alternate" href="https://mysolution.servicebus.windows.net/testqueues/" />
            <link rel="self" href="https://mysolution.servicebus.windows.net/testqueues/" />
        </entry>
        <entry>
            <id>uuid:6bbbd412-81e8-4f30-8629-909d8175e05a;id=560</id>
            <title type="text">testrouters</title>
            <updated>2009-08-05T21:08:29Z</updated>
            <link rel="alternate" href="https://mysolution.servicebus.windows.net/testrouters/" />
            <link rel="self" href="https://mysolution.servicebus.windows.net/testrouters/" />
        </entry>
    </feed>

We can see three entries in the feed each denoting a node in the registry. Submitting a similar request to the URL of a node will retrieve the Atom feed of its child nodes and so on. Here’s the Atom feed for the testrouters node :

<feed xmlns="http://www.w3.org/2005/Atom">
    <title type="text">Publicly Listed Services</title>
    <subtitle type="text">This is the list of publicly-listed services currently available</subtitle>
    <id>uuid:11e6ffbf-1463-46e5-9a3a-61b7f0966af0;id=349</id>
    <updated>2009-08-08T08:31:00Z</updated>
    <generator>Microsoft® .NET Services - Service Bus</generator>
    <entry>
        <id>uuid:11e6ffbf-1463-46e5-9a3a-61b7f0966af0;id=350</id>
        <title type="text">5922fd42-6120-44cd-b07a-c3a36bd70168</title>
        <updated>2009-08-08T08:31:00Z</updated>
        <link rel="alternate" href="https://mysolution.servicebus.windows.net/TestRouters/5922fd42-6120-44cd-b07a-c3a36bd70168" />
        <link rel="self" href="https://mysolution.servicebus.windows.net/TestRouters/5922fd42-6120-44cd-b07a-c3a36bd70168!(router)" />
        <link rel="subscriptions" href="https://mysolution.servicebus.windows.net/TestRouters/5922fd42-6120-44cd-b07a-c3a36bd70168!(router/subscriptions)" />
        <RouterPolicy xmlns="http://schemas.microsoft.com/netservices/2009/05/servicebus/connect" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
            <Authorization>Required</Authorization>
            <Discoverability>Managers</Discoverability>
            <ExpirationInstant>2009-08-08T08:50:14.9579043Z</ExpirationInstant>
            <TransportProtection>AllPaths</TransportProtection>
            <MaxMessageSize>61440</MaxMessageSize>
            <BufferTimeout>PT10S</BufferTimeout>
            <MaxBufferLength>0</MaxBufferLength>
            <MaxBufferCapacity>0</MaxBufferCapacity>
            <MaxSubscribers>50</MaxSubscribers>
            <MessageDistribution>AllSubscribers</MessageDistribution>
            <PushDeliveryRetries>3</PushDeliveryRetries>
            <PushDeliveryTimeout>PT30S</PushDeliveryTimeout>
        </RouterPolicy>
    </entry>
</feed>

That’s the entry for a router along with an Atom extension element describing the router policy.

Here’s the UI. It’s basically a TreeView for the registry nodes, a PropertyGrid for the node properties and a RichTextBox for the raw Atom.

Service Browser UI

Currently it will manage multiple solutions, walk the Atom tree, display the nodes and their properties, policies and subscriptions. It also allows you to delete queues and routers. Next steps, when I get a bit more time, are to fix the subscription display for the router nodes and to allow the creation of routers and queues (and perhaps subscriptions). Current impediments, other than time, are that the Atom feed to the subscription URL on a router always seems to come back empty even when there are subscriptions 😦

You can download the source here. Feedback and comments welcome unless they are a 17 page treatise on why I should have used [insert your favourite UI stack here] and the [insert your favourite pattern here] pattern 🙂

Please note : Since I wrote this article and posted the code there have been a number of changes to .NET Services, the Service Bus and the Access Control Service, most notably in the November CTP where, amongst other things, we lost Routers and Queues. As a result this code will no longer work. I am working on an updated solution that demonstrates the same functionality which I will post as soon as it’s ready.

Azure Service Bus Presentation and Demo Code

I presented to the UK Azure User Group at Microsoft in London last night. Thanks to everyone who came along and thanks also for all the kind words afterwards. I’m glad so many of you enjoyed it. As promised my slide deck and demo code are now available for download here.

I’ve tried to make the demo as self-contained as possible so anyone can get it up and running easily. However, please read the setup and prerequisite instructions included in the solution and if you have any problems don’t hesitate to drop me an email and let me know.

Also, if you think the .NET Services and Service Bus components of the Azure Services Platform are cool, exciting, compelling, interesting, useful, revolutionary or any of the other terms I heard used last night, please make some noise about it and about anything you are doing with them. Microsoft do monitor the community chatter during a CTP to guage the response to different features and we should be as quick, as loud and as forthright coming forward with our positive responses to these things as we are when they go wrong or we find bugs.

Thanks again.

Click Here to View The Video Titled: UK Azure User Group Meeting#2 Talk #2: EasyJet and Azure (Bert Craven)

Please note : Since this presentation there have been a number of changes to .NET Services, the Service Bus and the Access Control Service, most notably in the November CTP where, amongst other things, we lost Routers and Queues. As a result this code will no longer work.It would also seem that both the UKAzureNet site and ExposareRoom.com have shut down so there’s no video anymore 😦 I will attempt to find a backup 🙂

A Couple of Bugs (or not)

A couple of niggles have come to light today. The first one is that Windows Azure does not seem to support the latest version of the Azure .NET Services Bus. The recent release of the .NET Services SDK, the July CTP, included a new version of Microsoft.ServiceBus.dll (0.16.0.0). This version is not available on Windows Azure. After I had updated my SDK I rebuilt and redeployed a Windows Azure cloud application with a Web Role that calls service bus endpoints. This started throwing all kinds of odd exceptions which was confusing as it (of course) worked fine on my machine. I eventually tracked the issue down and the only way round it at the moment is to set the Copy Local property in the properties of the reference to Microsoft.ServiceBus.dll to true. That way it will get deployed with the application.

The second issue was a kind of two in one. I’m developing some prototypes for Windows Mobile using the .NET Compact Framework 3.5. One of the things I’m working on is a method of keeping mobile devices synchronised via .Net Service Bus queues and routers. There is no native support for the Service Bus on .NETCF but fortunately I only need to make REST calls using a meteor pattern to poll a queue for sync messages.

I had two problems. The first was that I could only poll a queue twice using HttpWebRequest before I’d start getting timeouts. This turned out to be because I was hitting the max connections limit (2 by default), even though I was carefully disposing of responses and closing response streams etc. The second was that I would always get an ObjectDisposedException at System.Threading.WaitHandle.CheckResultInternal when I closed the application. The polling of the queue was of course being done on a background thread, so looking at the two together it did seem that some resource was not being correctly released somewhere.

Looking into the stack trace of the ObjectDisposedException exception I could see references to HttpWebRequest and stream writes. It occurred to me that because I was using REST I was only ever sending headers in my HttpWebRequests, and no body. When I was calling WebRequest.Create() it was possible that the request stream was being opened and because I wasn’t using it it never got closed. As these requests were being created on my background thread they would not dispose correctly and they would continue to consume connection resources and possibly casue thread termination exceptions.

The answer was to close the request stream before sending the request :

try{    HttpWebRequest dequeueRequest = (HttpWebRequest)WebRequest.Create(_QueueHeadUri.AbsoluteUri + "?encoding=asreply&maxmessages=1&timeout=15");    dequeueRequest.ConnectionGroupName = "queueclient";    dequeueRequest.Method = "DELETE";    dequeueRequest.Timeout = 30000;    dequeueRequest.ContentLength = 0;    dequeueRequest.Headers.Add("X-MS-Identity-Token", this._AccessToken);    // this next line is the key     dequeueRequest.GetRequestStream().Close();    using (HttpWebResponse response = (HttpWebResponse)dequeueRequest.GetResponse())    {        if (response.StatusCode == HttpStatusCode.OK)        {            string viaString = response.Headers["X-REQUEST-HTTP-URI"];            Uri viaUri = new Uri(viaString);            if (this.OnMessageDequeued != null)            {                this.OnMessageDequeued(this, viaUri.Query);            }            continue;        }        if (response.StatusCode == HttpStatusCode.NoContent)        {            continue;        }        if (this.OnMessageDequeueError != null)        {            this.OnMessageDequeueError(this, new Exception(string.Format("HTTP Status Code : {0} : {1}", ((int)response.StatusCode), response.StatusCode)));        }    }}catch (Exception ex){    if (this.OnMessageDequeueError != null)    {        this.OnMessageDequeueError(this, ex);    }}

Code Quality

How not to scale

Speaking of scale there’s an interesting article here by Bart Smaalders of Sun Microsystems about performance anti-patterns. He has identified a number of these anti-patterns :

  • Fixing Performance at the End of the Project
  • Measuring and Comparing the Wrong Things
  • Algorithmic Antipathy
  • Reusing Software
  • Iterating Because That’s What Computers Do Well
  • Premature Optimization
  • Focusing on What You Can See Rather Than on the Problem
  • Software Layering
  • Excessive Numbers of Threads
  • Asymmetric Hardware Utilization
  • Not Optimizing for the Common Case
  • Needless Swapping of Cache Lines Between CPUs

Although it does appear to have been written from the perspective of “performance over all” and some sections (e.g. the one about layering) ignore that fact that the history of software development has been a gradual trade-off between performance and other equally important things like flexibility, maintainability, portability, modularity, productivity etc, it’s a short, well written article that makes interesting reading.

What not to code

The NSA, with contributions from, among others, :

  • CERT
  • Symantec
  • MITRE
  • Aspect Security
  • Secunia
  • iDefense Labs at VeriSign
  • Microsoft
  • Oracle Corporation
  • Red Hat Inc.
  • Fortify Software
  • Veracode
  • Breach Security
  • Security Division of EMC Corporation
  • Apple Product Security
  • Department of Homeland Security (DHS) National Cyber Security Division

have published a list of the 25 most dangerous programming errors that lead to security bugs and that enable cyber espionage and cyber crime.

Shockingly, most of these errors are not well understood by programmers; their avoidance is not widely taught by computer science programs; and their presence is frequently not tested by organizations developing software for sale.

These Top 25 Errors are divided in three categories:

  • Category: Insecure Interaction Between Components (9 errors)
  • Category: Risky Resource Management (9 errors)
  • Category: Porous Defenses (7 errors)

The list will be constantly updated and augmented with resources to help combat/prevent these errors.

Full article here : http://www.sans.org/top25errors/

Full list here : http://cwe.mitre.org/top25/

The keys to success

There is a list here of all the keyboard shortcuts in Windows. Wow ! That’s a lot of shortcuts. I’ve been using Windows forever and I’ll admit right now I only know a fraction of those.
Speaking of keyboards, there’s a great article here about the give and take in a software project, i.e. what developers should expect to contribute and what they should expect to receive in return. In short :

What can the project do for you?

First up we have a bunch of items along the lines of “I expect — maybe demand — that management will provide me with…”

  1. Two monitors
  2. A fast PC with a crapload of RAM
  3. Choice of mouse and keyboard
  4. A comfortable chair
  5. Quiet working conditions
  6. Internet unlimited
  7. Freedom to install software
  8. The best software
  9. Good coffee
  10. Sensible working hours
  11. Separate Environments for dev, qa and production

What can you do for the project?

But it’s not all “take take take”.

The other side of the equation are items along the lines of “I am committed to ensuring that these practices are performed…”

  1. Source Control
  2. Continuous integration
  3. Track bugs
  4. Unit testing
  5. Code analysis
  6. Continual peer review
  7. Peer training
  8. Keep yourself up to date
  9. Learn to Communicate with non-technical people
  10. Refactor!
  11. Passion
It’s a good list, but go read the full article as it goes into each item in more detail and with extra funny thrown in. File under “funny but true”.
Finally, check out Favrd. It’s a tracker that maintains a feed of all the tweets from twitter that are “yellow starred” or “favourited” (that is a thing, I swear) and ranks them daily by number of stars. It’s like cutting out all the mining and just being handed the gold.

Extending the WCF Stack

In my last post I created a custom serializer that could be injected into the WCF plumbing between the dispatcher and the service class that allowed us to debug errors that occurred during serialization. This operation behaviour could be applied to a method signature in the service contract :
 
[ServiceContract()]
public interface IMyService
{
	[OperationContract]
	[DebuggableSerializer]
	Thing GetThing(Flavour flavour); 
	
	[OperationContract]
	[DebuggableSerializer]
	Thing[] GetOneOfEach();
}
or to the implementation of that method in the service class :
 
[DebuggableSerializer]
public Thing[] GetOneOfEach()
{
	List<Thing> things = new List<Thing>();
	foreach(Flavour f in Enum.GetValues(typeof(Flavour)))
	{
		things.Add(this.GetThing(f));
	}
	return things.ToArray();
}
However, what if I wanted to apply this behaviour as a ServiceBehavior, ContractBehavior or EndpointBehavior rather than an OperationBehavior i.e. if I wanted all the operations in my service implementation or interface to use it and I don’t want to have to go through and add the attribute to every method ? How can I use my [DebuggableSerializer] attribute to decorate a service class, interface or even better, apply the behaviour to the service or endpoint using a config file so I don’t have to change my code at all ?
 
So, in this post I am going to extend my [DebuggableSerializer] attribute so it can be used on a service class or interface and I am going to extend the System.ServiceModel.Configuration.BehaviorExtensionElement to allow me to control and apply that behaviour from my config file to either a service or a specific endpoint.
 
My attribute in the previous example looked like this :
 
public class DebuggableSerializer : Attribute, IOperationBehavior
but now we want to use it as a ServiceBehavior, ContractBehavior and an EndpointBehavior as well as an OperationBehavior, so we’ll implement the IServiceBehavior, IContractBehavior and IEndpointBeahvior  interfaces :
 
public class DebuggableSerializer : Attribute, IOperationBehavior, 
	IServiceBehavior, IEndpointBehavior, IContractBehavior
IServiceBehavior has three methods for which we need to add implementations and IContractBehavior and IEndpointBehavior have 4 :
 
#region IServiceBehavior Members 

public void AddBindingParameters(ServiceDescription serviceDescription,
	ServiceHostBase serviceHostBase, 
	System.Collections.ObjectModel.Collection<ServiceEndpoint> endpoints,
	BindingParameterCollection bindingParameters)
{
	ReplaceDataContractSerializerOperationBehavior(serviceDescription);
}

public void ApplyDispatchBehavior(ServiceDescription serviceDescription,
	ServiceHostBase serviceHostBase)
{
	ReplaceDataContractSerializerOperationBehavior(serviceDescription);
} 

public void Validate(ServiceDescription serviceDescription,
	ServiceHostBase serviceHostBase)
{
} 

#endregion

#region IEndpointBehavior Members 

public void AddBindingParameters(ServiceEndpoint endpoint,
	BindingParameterCollection bindingParameters)
{
} 

public void ApplyClientBehavior(ServiceEndpoint endpoint,
ClientRuntime clientRuntime)
{
	ReplaceDataContractSerializerOperationBehavior(endpoint);
} 

public void ApplyDispatchBehavior(ServiceEndpoint endpoint,
	EndpointDispatcher endpointDispatcher)
{
	ReplaceDataContractSerializerOperationBehavior(endpoint);
} 

public void Validate(ServiceEndpoint endpoint)
{
}

#endregion

#region IContractBehavior Members 

public void AddBindingParameters(ContractDescription contractDescription,
	ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
{ 
} 

public void ApplyClientBehavior(ContractDescription contractDescription,
	ServiceEndpoint endpoint, ClientRuntime clientRuntime)
{
	ReplaceDataContractSerializerOperationBehavior(contractDescription);
} 

public void ApplyDispatchBehavior(ContractDescription contractDescription,
	ServiceEndpoint endpoint, DispatchRuntime dispatchRuntime)
{
	ReplaceDataContractSerializerOperationBehavior(contractDescription);
} 

public void Validate(ContractDescription contractDescription,
	ServiceEndpoint endpoint)
{ 
} 

#endregion
We also need to provide 3 overloads of the ReplaceDataContractSerializerOperationBehavior method, one that takes ServiceDescription, one that takes ServiceEndpoint and one that takes ContractDescription instead of OperationDescription. The method that takes ServiceDescription will call the method that takes ServiceEndpoint for each Endpoint and the method that takes ServiceEndpoint will call the method that takes ContractDescription and the method that takes ContractDescription will call the method that takes OperationDescription for each OperationDescription in its contract.
 
private static void ReplaceDataContractSerializerOperationBehavior(
	ServiceDescription description)
{
	foreach (ServiceEndpoint endpoint in description.Endpoints)
	{
		ReplaceDataContractSerializerOperationBehavior(endpoint);
	}
}

private static void ReplaceDataContractSerializerOperationBehavior(
	ContractDescription description)
{
	foreach (OperationDescription desc in description.Operations)
	{
		ReplaceDataContractSerializerOperationBehavior(desc);
	}
} 

private static void ReplaceDataContractSerializerOperationBehavior(
	ServiceEndpoint endpoint)
{
	// ignore mex
	if (endpoint.Contract.ContractType == typeof(IMetadataExchange))
	{
		return;
	}
	ReplaceDataContractSerializerOperationBehavior(endpoint.Contract);
}
So now we can take our DebuggableSerializer attribute and place it on the service class or interface :
 
[DebuggableSerializer]
public class MyService : IMyService
{ ... }

[DebuggableSerializer]
public interface IMyService
{ ... }
We now have an attribute that can be used to replace the serializer on a service contract or an operation contract or a service operation or on a whole service class or an endpoint of a service. The final step is to be able to add this behaviour to a service or an endpoint from within our configuration rather than in code. For this we need to create a BehaviorExtensionElement that will create an instance of our DebuggableSerializer behaviour. This is very simple :
 
public class UseDebuggableSerializer : BehaviorExtensionElement
{ 
	public override Type BehaviorType
	{
		get { return typeof(DebuggableSerializer); }
	}
	
	protected override object CreateBehavior()
	{
		return new DebuggableSerializer();
	}
}
Next, in our config file, we need to define this behaviour extension :
 
<system.serviceModel>
	<extensions>
		<behaviorExtensions>
			<add name="UseDebuggableSerializer"
				type="WCFLibrary.UseDebuggableSerializer, WCFLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
		</behaviorExtensions>
	</extensions>
	<!-- elided -->
</system.serviceModel>
To add this behaviour to a service we add the extension to the service’s assigned behaviour :
 
<system.serviceModel>
	<!-- elided -->
	<behaviors>
		<serviceBehaviors>
			<behavior name="MetadataExchange">
				<serviceMetadata httpGetEnabled="true" />
				<UseDebuggableSerializer />
			</behavior>
		</serviceBehaviors>
	</behaviors>
	<!-- elided -->
</system.serviceModel>
To add it to an endpoint we define an endpoint behaviour and add the extension to that :
 
<system.serviceModel>
	<!-- elided -->
	<behaviors>
		<endpointBehaviors>
			<behavior name="DebuggableSerializer">
				<UseDebuggableSerializer />
			</behavior>
		</endpointBehaviors>
	</behaviors>
	<!-- elided -->
	<service behaviorConfiguration="MetadataExchange" 
		name="WCFLibrary.MyService">
	<endpoint
		address="net.tcp://localhost:7000/MyService"
		behaviorConfiguration="DebuggableSerializer"
		binding="netTcpBinding"
		name="TCP_7000_MyService"
		contract="WCFLibrary.IMyService" />
	</service>
	<!-- elided -->
</system.serviceModel>

%d bloggers like this: