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:
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: }
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!
I am thrilled to share in the announcement that the first public CTP of Azure Service Bus Integration Services is now LIVE at http://portal.appfabriclabs.com.
The focus of this release is to enable you to build hybrid composite solutions that span on-premise investments such as Microsoft SQL Server, Oracle Database, SAP, Siebel eBusiness Applications, Oracle E-Business Suite, allowing you to compose these mission critical systems with applications, assets and workloads that you have deployed to Windows Azure, enabling first-class hybrid integration across traditional network and trust boundaries.
In a web to web world, many of the frictions addressed in these capabilities still exist, albeit to a smaller degree. The reality is that as the web and cloud computing continue to gain momentum, investments on-premise are, and will continue to be critical to realizing the full spectrum of benefits that cloud computing provides both in the short and long term.
So, what’s in this CTP?
Azure Service Bus Connect provides a new server explorer experience for LOB integration exposing a management head that can be accessed on-prem via Server Explorer or PowerShell to create, update, delete or retrieve information from LOB targets. This provides a robust extension of the Azure Service Bus relay endpoint concept, which acts a LOB conduit (LobTarget, LobRelay) for bridging these assets by extending the WCF LOB Adapters that ship with BizTalk Server 2010. The beauty of this approach is that you can leverage the LOB Adapters using BizTalk as a host, or, for a lighter weight way approach, use IIS/Windows Server AppFabric to compose business operations on-premise and beyond.
In addition, support for messaging between trading partners across traditional trust boundaries in business-to-business (B2B) scenarios using is EDI is also provided in this preview, including AS2 protocol support with X12 chaining for send and receive pipelines, FTP as transport for X12, agreement templates, partners view with profiles per partner, resources view, and an intuitive, metro style EDI Portal
.
Just as with on-premise integration, friction always exists when integrating different assets which may exist on different platforms, implement different standards and at a minimum have different representations of common entities that are part of your composite solution’s domain. What is needed is a mediation broker that can be leveraged at internet-scale, and apply message and protocol transformations across disparate parties and this is exactly what the Transforms capability provides. Taking an approach that will be immediately familiar to the BizTalk developer, a familiar mapper-like experience is provided within Visual Studio for interactively mapping message elements and applying additional processing logic via operations (functoids).
In addition, XML Bridges which include the XML One-Way Bridge and XML Request-Reply Bridge are an extension to the Azure Service Bus which supports critical patterns such as protocol bridging, routing actions, external data lookup for message enrichment and support for both WS-I and REST endpoints and any combination thereof.
As shown below in the MSDN documentation, “bridges are composed of stages and activities where each stage is a message processing unit in itself. Each stage of a bridge is atomic, which means either a message completes a stage or not. A stage can be turned on or off, indicating whether to process a message or simply let it pass through”.
Taking a familiar VETR approach to validate, extract, transform and route messages from one party to another, along with the ability to enrich messages by composing other endpoint in-flight (supported protocols include HTTP, WS-HTTP and Basic HTTP, HTTP Relay Endpoint, Service Bus Queues/Topics and any other XML bridge) the Bridge is a very important capability and brings very robust capabilities for extending Azure Service Bus as a key messaging broker across integration disciplines.
In reality, these patterns have no more to do with EAI than with traditional, contemporary service composition and become necessary once you move from a point-to-point approach and need to elegantly manage integration and composition across assets. As such, this capability acts as a bridge to Azure Service Bus that is very powerful in and of itself, even in non-EAI/EDI scenarios where endpoints can be virtualized increasing decoupling between parties (clients/services). In addition, this capability further enriches what is possible when using the BrokeredMessage property construct as a potential poor-man’s routing mechanism.
In closing, the need to address the impedance mismatch that exists between disparate applications that must communicate with each other is a friction that will continue to exist for many years to come, and while traditionally, many of these problems have been solved by expensive, big iron middleware servers, this is changing.
As with most technologies, often new possibilities are unlocked that are residual side-effects of something bigger, and this is certainly the case with how both innovative and strategic Azure Service Bus is to Microsoft’s PaaS strategy. Azure Service Bus continues to serve as a great example of a welcomed shift to a lightweight capability-based, platform-oriented approach to solving tough distributed messaging/integration problems while honoring the existing investments that organizations have made and benefiting from a common platform approach which is extremely unique in the market. And while this shift will take some time, in the long-run enterprises of all shapes and sizes only stand to benefit.
To get started, download the SDK & samples from http://go.microsoft.com/fwlink/?LinkID=184288 and the tutorial & documentation from http://go.microsoft.com/fwlink/?LinkID=235197 and watch this and the Windows Azure blog for more details coming soon.
Happy Messaging!