Wednesday, May 16, 2012
June 14th 2012 @ Microsoft Southwest District Office in Tempe, AZ
Registration is required. Please visit pcsug.org for more information and to register for this event: http://pcsug.org/Home/Events
You asked for it, and here it is.
As a user group that is exclusively focused on distributed computing, the appeal of Node.js to a bunch of messaging guys is obvious. Node.js is new, fascinating and seductive. 
After much excitement and buzz around Node.js in general and on Windows Azure in particular, PCSUG.org is thrilled to kick off the summer with Glenn Block, Senior Program Manager on the Node.js SDK for Windows Azure team.
Joining us from Redmond, Glenn will be sharing the latest on what the Azure SDK for Windows Azure has to offer, whether you are new to Node.js development or a seasoned veteran.
In addition, our own Developer Evangelist, J. Michael Palermo will help kick things off with a discussion on what the back-end developer needs to know about HTML5 and Windows 8.
Below is the agenda and logistics- we hope you'll join us for a great opportunity to learn about what Node.js on Windows Azure has to offer as well as network and connect with other members of the Phoenix developer community.
6:00 to 8:00 pm: "Unlock your Inner Node.js in the Cloud with Windows Azure" with Glenn Block, Senior Program Manager, Microsoft Corporation
If I told you that you can build node.js applications in Windows Azure would you believe me? Come to this session and I’ll show you how. You’ll see how take those existing node apps and easily deploy them to Windows Azure from any platform. You’ll see how you can make 
yours node apps more robust by leveraging Azure services like storage and service bus, all of which are available in our new “azure” npm module. You’ll also see how to take advantage of cool tools like socket.io for WebSockets, node-inspector for debugging and Cloud9 for an awesome online development experience.
About Glenn Block
Glenn is a PM at Microsoft working on support for node.js in Windows and Azure. Glenn has a breadth of experience both both inside and outside Microsoft developing software solutions for ISVs and the enterprise. Glenn has been a passionate supporter of open source and has been active in involving folks from the community in the development of software at Microsoft. This has included shipping products under open source licenses, as well as assisting other teams looking to do so. Glenn is also a lover of community and a frequent speaker at local and international events and user groups.
http://codebetter.com/glennblock/
https://twitter.com/gblock
5:30 to 6:00 pm: “What the back-end developer needs to know about HTML5 and Windows 8” with J. Michael Palermo, Senior Developer Evangelist, Microsoft Corporation
Understanding how client applications use and access data is essential for structuring and providing data through services. And just as back-end solutions evolve, so does the client. In this session, you will see how a Windows 8 Metro Style application written in JavaScript and HTML5 is developed to access data via REST APIs and web sockets.
About J. Michael Palermo:
J. “Michael” Palermo IV is a Developer Evangelist with Microsoft. In his years prior to joining Microsoft, Michael served as a Microsoft Regional Director and MVP. Michael has authored several technical books and has published online courses with Pluralsight on HTML5 technologies. Michael continues to share his passion for software development by speaking at developer events around the world.
http://www.palermo4.com
http://twitter.com/palermo4
Registration is required. Please visit pcsug.org for more information and to register for this event: http://pcsug.org/Home/Events
Friday, April 27, 2012
I am very proud to share the release of a brand new book on Windows Identity Foundation by my friend and Neudesic colleague Sandeep Chanda, “Microsoft Windows Identity Foundation Cookbook”
I had the privilege of being invited by Sandeep to write the foreword for the book and am honored at the opportunity to be associated with such a tremendous body of work.
At Neudesic, we strive to lead our teams and the customers we serve via a continuous feedback loop of best practices and guidance stemming from the collective experience of our consultants in the field over the last decade not only solving difficult software engineering problems through the application of technology, but bending the technology to deliver the desired business outcomes that our clients have partnered with us for.
Security is one of those topics that is bigger than any technology set or practice area. As such, the hard hitting, no-nonsense recipes in this book serve as pragmatic guidance for anyone contending with the myriad of forces at play in any modern software solution for which claims-based security is particularly well suited.
As I share in the foreword…
Careful to begin with easy to grasp fundamentals of claims-based security, Sandeep progresses through common WIF programming tasks using examples in ASP.NET and WCF familiar to most .NET developers while covering bleeding edge scenarios including new features exposed in Windows 8 and securing Windows Metro applications.
This book offers a combination of simple, intermediate and advanced scenarios, covering ADFS 2.0 and incorporating web identity providers such as Windows Live ID, Google, Yahoo!, and Facebook with the Azure Service Bus Access Control Service. Also covered are real-world scenarios you are likely to encounter for securing Microsoft SharePoint, SalesForce.com and Microsoft Dynamics CRM.
In addition to providing a hands-on, pragmatic reference that will be immediately valuable to your next project, this book is a reflection of Sandeep’s real-word experience successfully applying these concepts and techniques in the field, the value of which is worth the price of this book alone.
If you are serious about building claims/identity-aware services and applications on the .NET Framework and want to get started today, this book belongs in your library.
More info from Packt Pub: http://www.packtpub.com/microsoft-windows-identity-foundation-cookbook/book
Purchase on Amazon.com: http://www.amazon.com/dp/1849686203/?tag=packtpubli-20
Thursday, March 29, 2012
I had the pleasure of presenting at Spring DevConnections today in Las Vegas and as promised, below are the samples for each of my demos.
To recap. WebSocket brings full-duplex, bi-directional TCP sockets to web, desktop and mobile applications, introducing an alternative to XHR and long-polling, particularly when latency is a primary focus. What makes WebSocket so significant to developers in addition to providing a direct, socket-based connection is that it is standardized by both the IETF Hybi working group and W3C which has brought wide industry support across both browser vendors implementing the client support and platform vendors providing support for building WebSocket servers.
Microsoft has been an early champion of the WebSocket protocol, sharing some early investments via HTML5 Interoperability Labs website and maintaining that investment with support for the WebSocket protocol announced at //Build 11 which introduced WebSocket support to Windows 8, Windows Server 8. .NET 4.5 and IE 10 Developer Preview based on the hybi-10 specification.
With the release of .NET 4.5 Beta 1, all of the above have been updated to RFC 6455, which is the latest specification and expected to be final.
Along with broad native support for WebSockets in modern browsers like Chrome, IE 10, Safari and FireFox, the standardization dust has settled making this the right time to jump in.
In my talk, we took a lap around the WebSocket support in .NET 4.5, highlighting the APIs that Microsoft has made available in the Microsoft.WebSocket namespace that ships as a package on NuGet. While you can go as deep as you want in the new System.Net.WebSockets namespace that forms the core of Microsoft’s investment in the protocol, the Microsoft.WebSocket package provides higher level abstractions for developing WebSocket solutions today with WCF using WebSocketService and ASP.NET using WebSocketHandler.
Since .NET 4.5 and Window 8/Server 8 have not yet been released, it is currently not possible to deploy your .NET 4.5 applications to Windows Azure. That said, while Windows Azure will certainly be updated to support these key technologies following RTM, Azure supports a variety of non-Microsoft programming languages and platforms including Node.js.
Demonstrating the latest Azure SDK for Node.js, we got a fully RFC 6455 complain WebSocket service up and running on Windows Azure in a worker role running Node.js and using the WebSocket.IO module to integrate with Twitter’s Streaming API which provides a one-way firehose for tapping into Twitter’s event stream which proved to be a great example of using these capabilities together while having a little fun with HTML 5 JQuery and CSS 3.
| Demo | Summary | Artifacts | |
| Demo 1 | Live chat sample of Silverlight-based client and WCF Service running on Windows Azure.
Please note that this implementation is deprecated and will not be carried forward.
Instead, please use .NET 4.5 WebSocket support in WCF and ASP.NET.
| http://html5labs.cloudapp.net/WebSockets/ChatDemo/wsdemo.html | 
|
| Demo 2 | Simple “Hello World” example of ASP.NET ASHX handler using WebSocketHandler and HTML 5 client demonstrating a trivial “echo” service that displays the date/time each second.
Also included in the Demo 2 folder is a WCF version of the same implementation (which I did not demo during my talk).
| http://sdrv.ms/HofK53
Projects:
SimpleEventingSample
SimpleEventingService
Requires Visual Studio 11 Beta 1 & Windows 8/Windows 8 Server | 
|
| Demo 3 | Example of using the Twitter Search API as an event stream with WCF using WebSocketService, Linq to Twitter and HTML 5 with some nice JQuery and CSS animation.
| http://sdrv.ms/HofK53
Projects:
StatusStreamClient
StatusStreamService
StatusStreamServiceTests
Requires Visual Studio 11 Beta 1 & Windows 8/Windows 8 Server | 
|
| Demo 4 | Another event streaming example, this time using the Twitter Streaming API, Node.js and WebSocket.IO in Windows Azure and HTML 5 animations with CSS 3 box shadow and rotate.
As opposed to the Twitter Search API used in Demo 3, you can see that events are immediately captured and the Streaming API is much more reliable than the Search API.
| http://sdrv.ms/H1DVru
Use any text editor or your favorite JavaScript IDE.
| 
|
| Deck | |
http://sdrv.ms/Hf5oZB | |
Please feel free to play with any of the samples, extend them and make them your own.
Please remember that demos 2 and 3 require .NET 4.5 Consumer Preview and either Windows 8 or 
Windows 8 server.
Since the Microsoft.WebSockets NuGet package is the easiest way to get started with WebSocketHandler and WebSocketService, I’d recommend starting with Demo 2 and Demo 3.
For demo 4, you will need an Azure account which you can sign up for free (really, free) at http://azure.com
As we discussed during my talk, even though .NET 4.5 and Windows 8 are not yet RTM:
•Now is the time to dive into WebSockets in .NET 4.5!
•Consider how WebSockets can improve existing near real-time messaging scenarios.
•Start building WebSocket apps on Windows 8 and Windows Server 8 today.
•.NET 4.5 support in Windows Azure is coming soon. In the meantime, consider alternate frameworks like Node.js which is supported today!
Last but not least, here are the resources I provided on my last slide for easy access:
•Microsoft.Web.WebSockets NuGet Package: http://nuget.org/packages/Microsoft.WebSockets
•Paul Batum’s blog: http://www.paulbatum.com/2011/09/getting-started-with-websockets-in.html
•Damir Dobric’s blog on WCF WebSockets: http://developers.de/blogs/damir_dobric/archive/2011/11/26/wcf-duplex-via-websocket.aspx
•ASP.NET Documentation:
●http://msdn.microsoft.com/en-us/library/system.web.websockets%28v=vs.110%29.aspx
●http://msdn.microsoft.com/en-us/library/system.net.websockets%28v=vs.110%29.aspx
•WebSocket.IO: https://github.com/learnboost/websocket.io
•Nice CSS & JQuery scripts/samples: http://marcofolio.net
Last but not least, I’d like to thank @paulbatum, PM at Microsoft working on the WCF and ASP.NET WebSocket features for helping me grok WebSockets in .NET 4.5. His guidance and thought leadership around WebSocket are invaluable to the community, so if you run into Paul, thank him or better yet, buy him a beer.
Happy Messaging!
Thursday, March 01, 2012
Workflows can get big pretty quickly.
VS 2010 required scrolling vertically and horizontally to navigate larger, more complex workflows.
VS 2011 brings panning which is a much more natural way to navigate.
2010: No Pan
2011: Pan, yay.
Learn more about the designer improvements in WF 4.5 here: http://msdn.microsoft.com/en-us/library/hh305677(VS.110).aspx
Workflows are visually descriptive by their nature, but sometimes it is helpful to add a note that further describes, or annotates an activity as a step in a process, or serve as a way to add a note during a code/design review, for example.
With annotations, you simply right click an activity and select Annotation. Both hidden and pinned modes are supported.
Here is an example of an annotation that is pinned. When you click on the post-it note looking icon in the upper right hand corner of the activity (hidden mode), the annotation will appear:
If you pin the annotation, it will be in-lined within the activity canvas itself:
Learn more about the designer improvements in WF 4.5 here: http://msdn.microsoft.com/en-us/library/hh305677(VS.110).aspx
Nothing against VB, but many (read most) .NET developers love their curly braces and semicolons.
WF 4.5 now supports C# expressions giving you the choice to keep your VB projects or go with C#, all the way, baby!
Learn more about the designer improvements in WF 4.5 here: http://msdn.microsoft.com/en-us/library/hh305677(VS.110).aspx
Wednesday, February 29, 2012
Previous versions of WCF only offered nested automated WSDL generation which can cause problems with 3rd party tools and other client stacks.
Flat WSDL is now an option for every WSDL/IMetadataExchange endpoint.
Learn more about the great productivity improvements to WCF 4.5 here: http://msdn.microsoft.com/en-us/library/dd456789(v=vs.110).aspx
Async is hard. C# 5 makes it easier. WCF 4.5 loves Tasks.
Learn more about the great productivity improvements to WCF 4.5 here: http://msdn.microsoft.com/en-us/library/dd456789(v=vs.110).aspx
Check out this proxy configuration file. See what's missing? All that useless default configuration is just that- default.
In WCF 4.5, you get a nice, clean conventional client config. Combined with intellisense, you can override the defaults very easily, keeping your client configuration manageable and your Ops folks happy.
Learn more about the great productivity improvements to WCF 4.5 here: http://msdn.microsoft.com/en-us/library/dd456789(v=vs.110).aspx
Late-Bound validation of WCF config is too late.
WCF 4.5 brings validation to Visual Studio 11 via warnings so that you catch them before you hit F5.
Learn more about the great productivity improvements to WCF 4.5 here: http://msdn.microsoft.com/en-us/library/dd456789(v=vs.110).aspx
How many times have you tried to remember what that Name attribute maps to? Is it your friendly name for the service or the type itself?
In building on the simplified configuration experience from WCF 4, WCF 4.5 adds much needed intellisense to make the config experience as simple as possible.
![Intellisense_thumb[1]](http://rickgaribay.net/Images/customcontent/0d88091a44b4_A4D7/Intellisense_thumb1_thumb.png "Intellisense_thumb[1]")
Learn more about the great productivity improvements to WCF 4.5 here: http://msdn.microsoft.com/en-us/library/dd456789(v=vs.110).aspx
Ever wonder what that pesky system.ServiceModel element or attribute is for?
WCF 4.5 adds much asked for tool tips on every element and attribute in the WCF configuration file to keep you productive and save you round trips to MSDN.
Learn more about the great productivity improvements to WCF 4.5 here: http://msdn.microsoft.com/en-us/library/dd456789(v=vs.110).aspx
Saturday, January 28, 2012
I recently got bitten by the Node.js bug. Hard.
If you are even remotely technically inclined, it is virtually impossible to not be seduced by the elegance, speed and low barrier to entry of getting started with Node.js. After all, its just another JavaScript API, only this time designed for running programs on the server. This in and of itself, is intriguing, but there has to be more, much more, to compel legions of open source developers to write entire libraries for Node almost over night, not to mention industry giants like Wal-Mart and Microsoft embracing this very new, fledgling technology that has yet to be proven over any significant period of time.
As intriguing as Node is, I have a hard time accepting things at face value that I don't fully understand. When I don’t understand something, I get very frustrated. This frustration usually motivates me to relentlessly attack the subject with varying degrees of success (and sometimes even more frustration!).
As such, this post is an attempt to collect my findings on how Node, and it’s alleged single-threaded approach to event-driven programming is different from what I know today. This is not a dissertation on event vs. thread-based concurrency or a detailed comparison of managed frameworks and Node.js. Instead, this is a naive attempt to capture my piecemeal understanding of how Node is different into a single post in hopes that comments and feedback will increase its accuracy in serving as a reference that helps to put in perspective for .NET developers how Node is different and what the hubbub is really all about.
To that end, I sincerely would appreciate your comments and feedback to enrich the quality of this post as I found resources on the web that tackle this specific topic severely lacking (or I am just too dense to figure it all out).
I’m going to skip the hello world code samples, or showing you how easy it is to spin up an HTTP or TCP server capable of handling a ridiculous amount of concurrent requests on a laptop because this is all well documented elsewhere. If you haven’t ever looked at Node before, check out the following resources which will help to kick-start your node.js addiction (the first hit is free):
Aside from the syntactic sugar that is immediately familiar to legions of web developers regardless of platform or language religion, you can’t come across any literature or talk on Node.js without a mention of the fact that what makes it all so wonderful is the fact that it is event-driven and single-threaded.
It is evident to me that there are either a lot of people that are much smarter than me and just instantly get that statement, as well as people that blindly accept it. Then there are those who haven’t slept well for the last week trying to figure out what the hell that means and how it’s different.
Event-driven. So what?
I’ve written lots of asynchronous code and designed many messaging solutions on event-driven architectures. As a Microsoft guy, I’m pretty familiar with writing imperative code using Begin/End, AsyncCallbacks, WaitHandles, IHttpAyncHandlers, etc. I’ve opted for ever permutation of WCF instancing and concurrency depending on the scenario at hand, and written some pretty slick WF 4 workflows that parallelize activities (yes, I know, its not really truly parallel, but in most cases, close enough). My point is, I get async and eventing, so what’s the big deal and how is Node any different than this, or the nice new async language features coming in C# 5?
IIS and .NET as a Learning Model
When learning something new, it is a tremendous advantage to know nothing about the topic and start fresh. Absent of that, it is usually helpful to have a familiar model that you can reference that helps you to compare and contrast a new concept, progressively iterating to understand the similarities and differences. As a career-long enterprise guy, working almost exclusively on the Microsoft platform, my model is IIS/WAS and .NET., so let’s summarize how a modern web server like IIS 7+ works which will provide the necessary infrastructure to help frame how .NET’s (or Java) execution model works.
As described on Learn.IIS.net, the following list describes the request-processing flow that is shown to your right:
- When a client browser initiates an HTTP request for a resource on the Web server, HTTP.sys intercepts the request.
- HTTP.sys contacts WAS to obtain information from the configuration store.
- WAS requests configuration information from the configuration store, applicationHost.config.
- The WWW Service receives configuration information, such as application pool and site configuration.
- The WWW Service uses the configuration information to configure HTTP.sys.
- WAS starts a worker process for the application pool to which the request was made.
- The worker process processes the request and returns a response to HTTP.sys.
- The client receives a response.
Step 7 is where your application (which might be an ASP.NET MVC app, a WCF or WF service) comes in. When WAS starts a worker process (w3wp.exe) the worker process allocates a thread for loading and executing your application. This is analogous to starting a program and inspecting the process in Windows Task Manager. If you open 3 instances of the program, you will see 3 processes in task manager and each process will have a minimum of one thread. If an unhandled exception occurs in the program, the entire process is torn down, but it doesn’t affect other processes because they are isolated for each other.
Processes, however, are not free. Starting and maintaining a process requires CPU time and memory, both of which are finite, and more processes and threads require more resources.
.NET improves resource consumption and adds an additional degree of isolation through Application Domains or AppDomains. AppDomains live within a process and your application runs inside an AppDomain.
K. Scott Allen summarizes the relationship between the worker process and AppDomains quite nicely:
You’ve created two ASP.NET applications on the same server, and have not done any special configuration. What is happening?
A single ASP.NET worker process will host both of the ASP.NET applications. On Windows XP and Windows 2000 this process is named aspnet_wp.exe, and the process runs under the security context of the local ASPNET account. On Windows 2003 the worker process has the name w3wp.exe and runs under the NETWORK SERVICE account by default.
An object lives in one AppDomain. Each ASP.NET application will have it’s own set of global variables: Cache, Application, and Session objects are not shared. Even though the code for both of the applications resides inside the same process, the unit of isolation is the .NET AppDomain. If there are classes with shared or static members, and those classes exist in both applications, each AppDomain will have it’s own copy of the static fields – the data is not shared. The code and data for each application is safely isolated and inside of a boundary provided by the AppDomain
In order to communicate or pass objects between AppDomains, you’ll need to look at techniques in .NET for communication across boundaries, such as .NET remoting or web services.
Here is a logical view borrowed from a post by Shiv Kumar that helps to show this relationship visually:
As outlined in steps 1 – 7 above, when a request comes in, IIS uses an I/O thread to dispatch the request off to ASP.NET. ASP.NET immediately sends the request to the CLR thread pool which returns immediately with a pending status. This frees the IIS I/O thread to handle the next request and so on. Now, if there is a thread available in the thread pool, life is good, and the work item is executed, returning back to the I/O thread in step 7. However, if all of the threads in the thread pool are busy, the request will queue until a CLR thread pool thread is available to process the work item, and if the queue length is too high, users will receive a somewhat terse request to go away and come back later.
This is a bit of an extreme trivialization of what happens. There are a number of knobs that can be set in IIS and ASP.NET that allow you to tune the number of concurrent requests, threads and connections that affect both IIS and the CLR thread pool. For example, the IIS thread pool has a maximum thread count of 256. ASP.NET initializes its thread pool to 100 threads per processor/core. You can adjust things like the maximum number of concurrent requests per CPU (which defaults to 5000) and maximum number of connections of 12 per CPU but this can be increased. This stuff is not easy to grasp, and system administrators dedicate entire careers to getting this right. In fact, it is so hard, that we are slowly moving away from having to manage this ourselves and just paying some really smart engineers to do it for us, at massive scale.
That said, if you are curious or want to read more, Thomas Marquardt and Fritz Onion cover IIS and CLR threading superbly in their respective posts.
Back to the example. If all of your code in step 7 (your app) is synchronous, then the number of concurrently executing requests is equal to the number of threads available to concurrently execute your requests and if you exceed this, your application/service will simply grind to a halt.
This is why asynchronous programming is so important. If your application/service (that runs in step 7) is well designed, and makes efficient use of IO by leveraging async so that work is distributed across multiple threads, then there are naturally more threads always ready to do work because the the total processing time of a request becomes that of the longest running operation instead of the sum of all operations. Do this right, and your app can scale pretty darn well as long as there are threads available to do the work.
However, as I mentioned, these threads are not free and in addition, there is a cost in switching from the kernel thread to the IIS thread and the CLR thread which results in additional CPU cycles, memory and, latency.
It is evident that to minimize latency, you apps must perform the work they need to as quickly as possible to keep threads free and ready to do more work. Leveraging asynchrony is key.
Even in era where scaling horizontally is simply a matter of pushing a button and swiping a credit card, an app that scales poorly on premise will scale poorly in the cloud, and both are expensive. Moreover, having written a lot of code, and worked with and mentored many teams in my career, I’ll admit that writing asynchronous code is just plain hard. I’ll even risk my nerd points in admitting that given the choice, I’ll write synchronous code all day long if I can get away with it.
So, what’s so different about Node?
My biggest source of confusion in digging into Node is the assertion that it is event-based and single threaded.
As we’ve just covered in our learning model, IIS and .NET are quite capable of async, but it certainly can’t do that on a single thread.
Well, guess what? Neither can Node. Wait, there’s more.
If you think about it for just a few seconds, highly concurrent, event-driven and single threaded do not mix. Intentional or otherwise, “single threaded” is a red herring and something that has simply been propagated over and over. Like a game of telephone, it’s meaning has been distorted and this is the main thing that was driving me NUTS.
Let’s take a closer look.
In Node, an program/application is created in a process, just like in the .NET world. If you run Node on Windows, you can see an instance of the process for each .js program you have running in Task Manager.
What makes Node unique is *not* that it is single-threaded, it’s the way in which it manages event-driven/async for you and this where the concept of an Event Loop comes in.
To provide an example, to open a WebSocket server that is compliant with the latest IETF and W3C standards, you write code like this written by my friend Adam Mokan:
1: var ws = require('websocket.io')
2: , server = ws.listen(3000)
3:
4: server.on('connection', function (socket) {
5:
6: console.log('connected to client');
7: socket.send('You connected to a web socket!');
8:
9: socket.on('message', function (data) {
10: console.log('nessage received:', data);
11: });
12:
13: socket.on('close', function () {
14: console.log('socket closed!');
15: });
16: });
As soon as ws.listen(3000) executes, a WebSocket server is created on a single thread which listens continuously on port 3000. When an HTML5 WebSocket compliant client connects to it, it fires the ‘connection’ event which the loop picks up and immediately publishes to the thread pool (see, I told you it was only half the story), and is ready to receive the next request. Thanks to the V8 Engine, this happens really, really fast.
What’s cool is that the program *is* the server. It doesn’t require a server like IIS or Apache to delegate requests to it. Node is fully capable of hosting an HTTP or TCP socket, and it does do this on a single thread. On the surface, this is actually quite similar to WCF which can be hosted in any CLR process or IIS, and to take this analogy one step further, you could configure a self-hosted WCF service as a singleton with multiple concurrency for a similar effect. But, as you well know, there is a ton of work that now needs to be done from a synchronization perspective and if you don’t use async to carry out the work, your performance will pretty much suck.
Wait! You say. Other than an (arguably) easier async programming model, how is this different than IIS/WAS and ASP.NET or WCF? Take a look at this drawing from from a great post by Aarron Stannard who just happens to be a Developer Evangelist at Microsoft:
As you can see, there is more than one thread involved. I don’t mean this to sound like a revelation, but it is a necessary refinement to explain how the concurrency is accomplished. But, and it’s a BIG but, unlike .NET, you don’t have a choice but to write your code asynchronously. As you can see in the code sample above, you simply can’t write synchronous code in Node. The work for each event is delegated work to an event handler by the loop immediately after the event fires . The work is picked up by a worker thread in the thread pool and then calls back to the event loop which send the request on its way. It is kind of subtle, but the single thread is *almost* never busy and when it is, it is only busy for a very short period of time.
This is different from our model in at least 3 ways I can think of:
- Your code is aysnc by default, period.
- There is no context switching as the Event Loop simply publishes and subscribes to the thread pool.
- The Event Loop never blocks.
Your code is aysnc by default, period.
This can’t be understated. Writing asynchronous code is hard, and given the option, most of us won’t. In a thread-based approach, particularly where all work isn’t guaranteed to be asynchronous, latency can become a problem. This isn’t optional in Node, so you either learn async or go away. Since it’s JavaScript, the language is pretty familiar to a very, very wide range of developers.
Node is very low level, but modules and frameworks like Express add sugar on top of it that help take some of the sting out of it and modules like Socket.IO and WebSocket.IO are pure awesome sauce.
There is no context switching as the Event Loop simply publishes and subscribes to the thread pool
I am not a threading expert, but simple physics tells me that that 0 thread hops is better than a minimum of 3.
I guess this might be analogous to a hypothetical example where HTTP.sys is the only gate, and WWW Publishing Service, WAS, ASP.NET are no longer in play, but unless HTTP.sys was changed from a threaded approach for concurrency to an Event Loop, I’m guessing it wouldn’t necessarily be apples to apples.
With Node, while there are worker threads involved, since they are each carrying out one and only one task at a time asynchronously, the CPU and memory footprint should be lower than a multi-treaded scenario, since less threads are required. This tends to be better for scalability in a highly concurrent environment, even on commodity hardware.
The Event Loop never blocks.
This is still something I’m trying to get my head around, but conceptually, what appears to be fundamentally different is that the Event Loop always runs on the same, single I/O thread. It is never blocking, but instead waits for something to happen (a connection, request, message, etc.) before doing anything, and then, like a good manager, simply delegates the work to an army of workers who report back when the work is done. In other words, the worker threads do all the work, while the Event Loop just kind of chills waiting for the next request and while it is waiting, it consumes 0 resources.
One of the things that I am not clear on is that when the callbacks are serialized back to the loop, only one callback can be handled at one time, so, if a request comes in at the exact same time that the loop is temporarily busy with the callback, will that request block, even if just for the slightest instant?
So?
Obviously, still being very new to Node, I have a ton to learn, but it is clear that for highly concurrent, real-time scenarios, Node has a lot of promise.
Does this mean that I’m abandoning .NET for Node? Of course not. For one, it will take a few years to see how things pan out in the wild, but the traction that Node is getting can’t be ignored, and it could very well signal the shift to event-based server programming and EDA in the large.
I’d love to know what you think, and as I mentioned in the introduction, welcome your comments and feedback.
Resources:
Thursday, January 19, 2012
Azure Service Bus Brokered Messaging provides durable pull-based pub-sub, complimenting it’s older sibling Relay Messaging which uses a push messaging model. While both enable hybrid composition across traditional business, trust and network boundaries, they provide unique capabilities in and of themselves.
As with Relay Messaging, Brokered Messaging provides first class support for WCF with the NetMessagingBinding, but expands the developer surface to general .NET and cross-platform/mobility scenarios by offering the .NET Client and REST API respectively.
Of the 3 APIs, the .NET Client API is the most robust and seems to be the most documented.
The simplicity of the WCF programming model (the illusion that messages are being pushed to your endpoint) is balanced with some restrictions that naturally fall out of the scope of one-way messaging including queue/topic/subscription/rule creation and support for peek lock.
In this regard, while not as robust as the .NET Client API, the REST API offers a more comprehensive feature set and when working on solutions that must be interoperable across client platforms or due to other restrictions, the REST API is a great choice.
Microsoft has documented the REST API in the Service Bus REST API Reference, but there are not a ton of imperative examples out there that show WebClient or HttpWebRequest, so the purpose of this post is to share some nitty gritty examples of how to get some of the most common operations done in C#.
Please note that my goal is not to be elegant or use the tersest or most fluid syntax possible in this samples, but rather to get some quick and dirty examples out there, well, quickly.
As such, the unit tests should be self explanatory, but if you have any questions, please don’t hesitate to ask.
Feedback, comments related to the API or WebClient techniques welcome 
1: using System;
2: using System.Text;
3: using System.Collections.Generic;
4: using System.Linq;
5: using Microsoft.VisualStudio.TestTools.UnitTesting;
6: using System.Collections.Specialized;
7: using System.Net;
8: using System.Runtime.Serialization.Json;
9: using System.Runtime.Serialization;
10: using System.IO;
11:
12: namespace RESTAPITests
13: {
14: [TestClass]
15: public class RESTAPITests
16: {
17:
18: static string serviceNamespace = "[NAMESPACE]";
19: static string issuerName = "owner";
20: static string issuerSecret = "[KEY]";
21: const string sbHostName = "servicebus.windows.net";
22: const string acsHostName = "accesscontrol.windows.net";
23: static string relativeAddress = "[Queue]";
24: static string baseAddress;
25:
26:
27: [TestMethod]
28: public void SendMessageShouldSucceedWithoutError()
29: {
30: string body = "foo";
31:
32: var token = GetToken(issuerName, issuerSecret);
33:
34: baseAddress = GetBaseAddress();
35: string fullAddress = baseAddress + relativeAddress + "/messages";
36:
37: WebClient webClient = new WebClient();
38: webClient.Headers[HttpRequestHeader.Authorization] = token;
39: webClient.UploadData(fullAddress, "POST", Encoding.UTF8.GetBytes(body));
40:
41: }
42:
43: [TestMethod]
44: public void PeekLockMessageShouldReturnLockId()
45: {
46: var token = GetToken(issuerName, issuerSecret);
47:
48: baseAddress = GetBaseAddress();
49:
50: // Read and lock the message. Unless released, the lock will expire within the configured lock duration (on the queue)
51: string fullAddress = baseAddress + relativeAddress + "/messages/head";
52:
53: WebClient webClient = new WebClient();
54: webClient.Headers[HttpRequestHeader.Authorization] = token;
55: webClient.UploadData(fullAddress, "POST", new byte[0]{});
56:
57: var props = webClient.ResponseHeaders["BrokerProperties"];
58:
59: // Deserialize the JSON header to a simple class
60: DataContractJsonSerializer serializer = new DataContractJsonSerializer(typeof(BrokerProperty));
61: using (MemoryStream stream = new MemoryStream(Encoding.Unicode.GetBytes(props)))
62: {
63: var result = (BrokerProperty)serializer.ReadObject(stream);
64:
65: Assert.IsNotNull(result.LockToken);
66: }
67:
68: }
69:
70: [TestMethod]
71: public void PeekLockMessageAndAbandonShouldSucceed()
72: {
73: var token = GetToken(issuerName, issuerSecret);
74:
75: baseAddress = GetBaseAddress();
76:
77: // Read and lock the message. Unless released, the lock will expire within the configured lock duration (on the queue)
78: string fullAddress = baseAddress + relativeAddress + "/messages/head";
79:
80: WebClient webClient = new WebClient();
81: webClient.Headers[HttpRequestHeader.Authorization] = token;
82: webClient.UploadData(fullAddress, "POST", new byte[0] { });
83:
84: var props = webClient.ResponseHeaders["BrokerProperties"];
85:
86: // Deserialize the JSON header to a simple class
87: DataContractJsonSerializer serializer = new DataContractJsonSerializer(typeof(BrokerProperty));
88:
89: using (MemoryStream stream = new MemoryStream(Encoding.Unicode.GetBytes(props)))
90: {
91: var result = (BrokerProperty)serializer.ReadObject(stream);
92:
93: // Bail on the message, release the lock so it is available for another consumer
94: fullAddress = baseAddress + relativeAddress + String.Format("/messages/{0}/{1}", result.MessageId, result.LockToken);
95: }
96:
97: webClient = new WebClient();
98: webClient.Headers[HttpRequestHeader.Authorization] = token;
99: webClient.UploadData(fullAddress, "PUT", new byte[0] { });
100:
101: }
102:
103: [TestMethod]
104: public void PeekLockMessageAndCompleteShouldSucceed()
105: {
106: var token = GetToken(issuerName, issuerSecret);
107:
108: baseAddress = GetBaseAddress();
109:
110: // Peek lock the message
111: string fullAddress = baseAddress + relativeAddress + "/messages/head";
112:
113: WebClient webClient = new WebClient();
114: webClient.Headers[HttpRequestHeader.Authorization] = token;
115: webClient.UploadData(fullAddress, "POST", new byte[0] { });
116:
117: var props = webClient.ResponseHeaders["BrokerProperties"];
118:
119: DataContractJsonSerializer serializer = new DataContractJsonSerializer(typeof(BrokerProperty));
120:
121: using (MemoryStream stream = new MemoryStream(Encoding.Unicode.GetBytes(props)))
122: {
123: var result = (BrokerProperty)serializer.ReadObject(stream);
124:
125: // Complete the read operation, releasing the lock and deleting the message from the queue
126: fullAddress = baseAddress + relativeAddress + String.Format("/messages/{0}/{1}", result.MessageId, result.LockToken);
127: }
128: webClient = new WebClient();
129: webClient.Headers[HttpRequestHeader.Authorization] = token;
130: webClient.UploadData(fullAddress, "DELETE", new byte[0] { });
131: }
132:
133: [TestMethod]
134: public void DecodeJsonToTypeShouldAllowEasyExtractionOfProps()
135: {
136:
137: string payload = @"{""DeliveryCount"":3,""LockToken"":""4a1d4c96-9837-42a9-ad91-3ecf704eec40"",""LockedUntilUtc"":""Thu, 19 Jan 2012 01:22:44 GMT"",
""MessageId"":""4a4fa2c7d87a40a7b799625b9de69e42"",""SequenceNumber"":2,""TimeToLive"":922337203685}";
138:
139: DataContractJsonSerializer serializer = new DataContractJsonSerializer(typeof(BrokerProperty));
140:
141: using (MemoryStream stream = new MemoryStream(Encoding.Unicode.GetBytes(payload)))
142: {
143: var result = (BrokerProperty)serializer.ReadObject(stream);
144:
145: Assert.IsNotNull(result.MessageId);
146: }
147:
148: }
149:
150: [DataContract]
151: public class BrokerProperty
152: {
153: [DataMember]
154: public string DeliveryCount { get; set; }
155: [DataMember]
156: public string LockToken { get; set; }
157: [DataMember]
158: public string LockedUntilUtc { get; set; }
159: [DataMember]
160: public string MessageId { get; set; }
161: [DataMember]
162: public string SequenceNumber { get; set; }
163: [DataMember]
164: public string TimeToLive { get; set; }
165: }
166:
167:
168: // Helper
169: private static string GetBaseAddress()
170: {
171: return baseAddress = "https://" + serviceNamespace + "." + sbHostName + "/";
172: }
173:
174: // Helper, warmly borrowed from Service Bus Management Sample :-)
175: private static string GetToken(string issuerName, string issuerSecret)
176: {
177: var acsEndpoint = "https://" + serviceNamespace + "-sb." + acsHostName + "/WRAPv0.9/";
178:
179: // Note that the realm used when requesting a token uses the HTTP scheme, even though
180: // calls to the service are always issued over HTTPS
181: var realm = "http://" + serviceNamespace + "." + sbHostName + "/";
182:
183: NameValueCollection values = new NameValueCollection();
184: values.Add("wrap_name", issuerName);
185: values.Add("wrap_password", issuerSecret);
186: values.Add("wrap_scope", realm);
187:
188: WebClient webClient = new WebClient();
189: byte[] response = webClient.UploadValues(acsEndpoint, values);
190:
191: string responseString = Encoding.UTF8.GetString(response);
192:
193: var responseProperties = responseString.Split('&');
194: var tokenProperty = responseProperties[0].Split('=');
195: var token = Uri.UnescapeDataString(tokenProperty[1]);
196:
197: return "WRAP access_token=\"" + token + "\"";
198: }
199:
200: }
201:
202: }
Monday, January 16, 2012
I’d like to pass on some details regarding an event I will be speaking on in Irvine, CA on February 16th.
NuCon is a one day conference put on by my employer, Neudesic that features talks and content from fellow Neudesic colleagues like David Pallmann, Ted Neward and Simon Guest, just to name a few. 
As Irvine is Neudesic’s headquarters, the event provides a great opportunity to gain insight into the future of technology as seen by my fellow colleagues as well as providing pragmatic guidance that you can put to use the following day while networking with other Neudesic customers, executive management, partners and thought leaders to help guide your strategy on making the most of the tremendous opportunities that the Microsoft platform and Neudesic products have to offer.
In my talk, Hybrid Composition on the Microsoft Application Integration platform, I’ll share how organizations of all shapes and sizes can benefit from the improvement, automation and streamlining of their business operations through hybrid composition.
Abstract 
In today’s technology landscape, exposing key functional areas as traditional services or other means has become the norm for achieving agility and is a requirement for taking advantage of the dramatic improvements that modern middleware capabilities both on-premise and in the cloud provide.
As organizations adapt to this new hybrid model, a shift from a homogenous, single product, big iron approach to heterogeneous, best in class, capability-driven model is necessary for realizing the benefits of service-orientation and enabling the composition of these services on-premise, in the cloud and behind the firewall without making big spending commitments on a product that may only meet some of these needs.
The Microsoft platform offers a number of capabilities for achieving these goals across common Hosting, Workflow, Rules, EAI and Messaging workloads that allow you to choose the right capabilities for delivering your intended business outcomes.
BizTalk Server 2010 and Windows Server AppFabric 1.1 provide a comprehensive middleware platform for developing, deploying, and managing composite enterprise capabilities on-premise and Windows Azure Service Bus and Access Control Service allow you to extend your investments beyond traditional trust and network boundaries making the cloud and other partner/vendor endpoints merely an extension of your enterprise.
Come learn how Windows Server AppFabric, WCF, WF Services, BizTalk Server and Windows Azure can benefit your approach to building and supporting application services at enterprise scale while transcending traditional trust boundaries and enabling the hybrid enterprise.
To give you an idea of the breadth and depth of the sessions, in my talk, I’ll be talking about and showing live demos of the latest capabilities that enable you to build hybrid composite solutions to drive differentiation and innovation within your organization:
Windows Server AppFabric 1.1 Caching (On-Prem) Featuring:
- AppFabric distributed caching including implementing the Cache-Aside caching pattern and Read-Through caching, new in AppFabric 1.1
WF 4 Workflow Services (On-Prem) Featuring:
- State Machine Activity, new in .NET 4.1 and .NET 4.5
- AppFabric Connect BizTalk Mapper for WF 4 in AppFabric Connect
- Long-running workflows
- Workflow Correlation
- Composition with WCF services in Windows Azure
Windows Server AppFabric Deployment (On-Prem) Featuring:
- Easy deployment with Microsoft Web Deploy
- Windows Server AppFabric Configuration Experience
WCF hosting in Windows Azure Web Roles (Cloud) Featuring:
- Azure Web Role hosting
- Azure Service Bus Topic client
Azure Service Bus Brokered Messaging (Hybrid) Featuring:
- Brokered messaging from Azure to on-premise custom applications behind the firewall
- Topics and Subscriptions
BizTalk Server 2010 Orchestration & Messaging (On-Prem) Featuring:
- Custom WCF Adapter for consuming messages off an Azure Service Bus Topic
- Support for custom WCF behaviors
- Support for hybrid ERP integration such as Dynamics CRM or SAP
So, if you are interested in attending, please consider yourself invited! Click on the links in the invitation below to register (save $100 if you register before Feb 1) and I look forward to seeing you at NuCon 12!