I know I havent been posting deep technical stuff that I used to do. Contrary to what people think my current role entails, keeping abreast of the technology landscape is what I am supposed to do and what I enjoy and so when colleagues joked with me when was the last time I booted up Visual Studio, for example, I enjoyed seeing their shocked faces when I told them: "oh - just last night. why you asked ?" .

I dont dwell deep like I used to but I still code up decent projects which I implement within my own developmental testing environment (yes, I have one running latest versions of Active Directory, SharePoint, Exchange and all the other goodies), driving the houshold crazy when I think of new and different ways to document expenses, publish a Book or CD library, home automation projects using all sorts of different technologies (yes, that includes Ruby-on-Rails) or in my new Windows Mobile 6 Device. Of course, I admit I dont post topics deep like I used to. It is not so much the content but more so, the limiting factor of time.

Recently, I was involved in some internal technical discussions with regards to the issue of scale comparisions between Windows Communication Foundation (WCF, previously - Indigo) and ASMX. Below are some discussions:

If you have a web service that is going to be IO bound, you would definitely want it to be scalable and almost every resource in the world tells you to implement ASP.NET asynchronous pattern (BeginSomething/EndSomething, etc) on it so to go easy on the thread pool. ASP.NET uses an IAsyncHttpHandler to handle the request, which means the worker threads are not blocked while the IO-bound operation executes somewhere else. Sounds good so far.

If you make a WCF version of it with webHttpBinding (which actually means you can invoked it AJAX-style) following the same async pattern for the methods, you may find that each invocation of the WCF service eats up two threads – one for its ASP.NET HttpModule.ProcessRequest and the other for the actual IO. Ouch! You may think that this means your WCF implementation may end up eating all threads reserved for ASP.NET, which would indeed scale down the server

Is this true OR are we missing the complete picture ?

While the scenarios explained above are reasonable observations, it doesnt paint the complete picture. WCF does perform better scalability than ASMX.

• Threading:
  For ASMX, when a request comes in, it would be queued up immediately for async ASMX. So the thread is released for that request and a new thread will pick up the work item later.

For WCF, when a request comes in, we queue it up in WCF and let an IO thread handle the request. At the same time, the request thread-pool thread is held to wait for the request to complete.

Yes, WCF uses more threads than async ASMX. But there is a reason for this. Using asynchronous ASMX is dangerous and not really a good practice (and I have hinted at this many times in the many Web Service/ASMX presentations I have done over the past few years). While it does well at what it is supposed to do, it does trick the developer into a "false sense of security". Essentially, if you dont know how the ASP.NET blackbox works, you may find yourself thrown against the car wall when you take a hidden, unsuspecting corner at high speeds. It does not provide enough throttling for client loads. Basically the server takes all items and queue them up for later processing. The server does not have a good throttling mechanism to control the number of work items. To everyone else, it seems that the server is quite friendly to all clients. However, if the number of clients is unbounded, this is really bad. First of all, the server working set would grow unlimited due to unlimited requests queued up. Secondly, many client requests would become obsolete when it’s picked up by the server from the queue. The latter accounts for a a good set of problematic scenarios I have come across in my past consulting gigs with regards to high-load and high-transactional ASMX asynchronous implementations before I joined the borg.

Think of it as a side of the brain (that tells you that you are about to be full) not functioning properly when you sit down at a buffet table. You eat and eat and eat without knowning when to stop and then your ingestion/digestion system starts kicking in, you actually hit the wall. Hard. Literally.

• Server Throughput
  When you measure scalability, the most important measurement is the server throughput. That is, how many requests the server can handle per time unit? For async ASMX, it would be pretty fast at the initial phase. However, like the ingestion/digestion analogy I was referring to above - Once the server is in a steady phase (as when CPU is fully loaded), the throughput will go down because the server capacity has reached. You can compare the data between async ASMX and sync ASMX over the long run to see what I mean.

Also you would see higher memory usage of the async approach.

• ASP.NET Throttling
  That said, ASP.NET does have a throttling mechanism that is used for sync ASMX, which is the threadpool thread limit. The number of threads used to handle requests are bounded (http://support.microsoft.com/kb/821268). WCF uses this fact to throttle incoming requests. You can always change the configuration settings to increase number of threads to be used to allow more work items to be queued up.

The max number of threads follows the following formula:
MaxWorkerThreads x #CPU – MinFreeThreads
This is 12 by default on a single-proc machine.

• Two-level Throttling for WCF
  WCF leverages the ASP.NET threadpool throttling to throttle client requests. At the same time, WCF has its own item queue throttling. The former is throttled by the setting mentioned in the immediate above point, while the latter is controlled by WCF throttling settings (maxConcurrentCalls etc). ASP.NET can automatically adjust threads based on CPU loads so that you would always get full load of the server.

In this way, you may experience client failures because the requests are rejected at ASP.NET layer beforehand. So you can increase the ASP.NET throttling to get better experience. But eventually you would still be bounded by the physical server capacity, no matter whether you use async ASMX, sync ASMX, or WCF as mentioned above.

There is improvement work done in .NET 3.0 SP1 and of course, .NET 3.5 (beta 2 here), with the use of prioritized item queues. Do expect even-better WCF performance even in some of the common scenarios. Fine tuning minWorkerThreads will even give us even better results.

Thanks to Wenlong for helping out with the guidance and explanation. The complete scenario and the design principles for it will be published in greater detail in a MSDN whitepaper later. Do watch out for it.

Two of my favourite features out of many in Visual Studio 2005.

1) Finally - A Correction of what was wrong for some time - There is a Add Service Reference now. This is essentially what svcutil.exe does for you. Awesome. Now we know we are speaking services and messages ... No more calls please.

2) A simple IDE enhancement but yet one that can generate lots of productivity. VS.NET will launch any project (of a solution) that my cursor is residing on. No more booting up of Class Libraries or Service Components by mistake anymore, (esp. in-front of an audience)

The WinFX Runtime Components Beta 1 is available here, and the WinFX SDK is available here.  Also, check out the new Windows Vista Developer Center at http://msdn.microsoft.com/windowsvista.

With this release comes with the official names for many of the technologies that they've been talking with our developers about for several years. In particular, Windows Longhorn is now Windows Vista, Avalon is now the Windows Presentation Foundation, and Indigo is the Windows Communication Foundation.

“Former” code name	Official name
Longhorn	Vista
Avalon	Windows Presentation Foundation
Indigo	Windows Communication Foundation
Metro	XML Paper Specification (XPS)
Least-privileged User Access	User Account Protection
WAP	WinFX Runtime Components

Please take a look at the new MSDN site serving as the single content point for current ASP.NET customers to easily make the move to ASP.NET 2.0.

Upgrade Center: http://msdn.microsoft.com/asp.net/migration/upgrade/default.aspx

Also, check out the new whitepaper that details the lessons learned, best practices, and valuable techniques that will help developers upgrade their apps.

New Upgrade Paper: http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/upgradingaspnet.asp

For general migration (ASP, competitive, etc.) content, you can always refer to the migration center at: http://msdn.microsoft.com/asp.net/migration/

The much anticipated download of a fully installed & configured Visual Studio 2005 Team System Beta 2 VPC is now available for download to MSDN Universal Subscribers. This is the same VPC that was distributed at TechEd USA and TechEd EMEA and represents a clean install of Windows Server 2003 w/ Visual Studio 2005 Team System Beta 2.

VPC Contents:

• Microsoft Windows Server 2003 Standard Edition
• Microsoft Visual Studio 2005 Team Suite Beta 2 (expires May 1, 2006)
• Microsoft Visual Studio 2005 Team Foundation Server Beta 2
• Microsoft .NET Framework 2.0 Redistributable Package Beta 2
• Microsoft SQL Server 2005 Community Technology Preview
• Microsoft Office 2003 Standard Edition
• Microsoft Live Communication Server 2003

This VPC does not contain any sample projects or sample data.

Minimum System Requirements:

• PC with 2.0 gigahertz or faster processor
• 1.5 GB RAM minimum
• 10 GB available hard disk space
• Super VGA (800 x 600) or higher video
• DVD-ROM drive
• Microsoft Virtual PC 2004 SP1 software

If you have some trouble locating this developer-Godsend --- I have done some snopping already and it is here:

Developer Tools > Visual Studio 2005 > Visual Studio 2005 Beta 2 > English > Visual Studio 2005 Team System Beta 2 VPC

I have recently flashed some performance graphs between Java 1.5 and the .NET counterparts version 1.1 and 2.0 Beta2. This is where I got the statistics from.

You will see the outright disparity in performance gains when .NET 2.0 Beta2 is put through the same tests with its poorer 1.1 brother and its distant cousin Java 1.5.

...And we are still talking about .NET 2.0 BETA 2 ... Let us see what happens when we get to November 7 2005

This has been floating around for some time BUT MSFT Corp has released an official statement here

Since XQuery is expected to reach W3C recommendation onlyin 2006, it won't be shipped in the upcoming .NET Framework 2.0

I guess people like me will have to live with XSLT and XPATH for now.

While doing some deep plumbing work, I discovered that Lutz Roeder's ultimate awesome Reflector() tool is already throwing up some wonderful Whidbey VB.NET keywords. AND I dont even have .NET 2.0 installed on that machine yet. Cool

One of the keywords used is TryCast. TryCast is a new VB.NET Keyword in VS2005 which essentially combines 2 type checks into 1. For example

Instead of

Do this

Of course, performance is the differentiating issue here. TryCast, as its name suggests, will try the cast and, if it succeeds, return the value cast to that type, else, it returns nothing.

Think of it as VB.NET's answer to C# “As” keyword. Here is also a good blog about it.

One of the most wonderful enhancements to ASMX v2.0 is to bring the age-old classic Event-Based Asynchronous into the proxy stubs of the client.

This Event-Based paradigm has been around for a while since the “legacy” VB Days. It adds another layer of abstraction on top of delegates and callbacks which makes it a lot simpler to code and easier on the design and your eyes as well.

The new event-based asynchronous programming model simplifies the task of invoking a Web service asynchronously. In addition to using an event paradigm instead of Begin<YourMethodNameHere> and End<YourMethodNameHere>, the new programming model also takes care of thread synchronization automatically so that event handlers are invoked on the same thread that made the asynchronous call.

There is an article here by Yasser, Matt and Co. that sums up the this Event-Based Asynchronous Programming. I will further rip open the proxy stubs to examine the inner plumbings here.

If you use WSDL v2.0.40607.16 to generate the classes from the contracts, you will find that the new generated classes contain a lot more methods and properties. Yes, thats right, most of the functionality will be exposed as properties rather than fields now, which makes dataBinding easier. If you choose to retain the fields as of .NET 1.*, there is a switch /fields in the WSDL command line option that allows you to do so.

One of the most obvious thing that catches the eye is the amount of new methods that are generated that deals with asynchronous programming of Web Services. This makes a lot of sense once people start to move their mindset away from the “RPC-ish” behavior of Web Services. Of course, this whole sense of asynchronous programming is still rather “RPC-ish” hidden behind the shrouds of multi-threaded programming. It will take a while before people can move away from that and accept the different programming models that SOAP can offer besides that of client-server dialogs. This will be the advent of Service-Orientation which some of us are trying to drive into the mainstream.

The older way of using Delegates and Callbacks with Begin<YourMethodNameHere> and End<YourMethodNameHere> are still there in ASMX v2.0 and rightfully so, as this method of programming, altho slightly clunkier, offers limitless ways to handle threads and callbacks.

On the other hand, this Event-Based Asynchronous paradigm is NOT too shabby either...:)

I will just produce relevant snippets of what is in the proxy stubs generated by WSDL v2.0.40607.16

<System.Diagnostics.DebuggerStepThroughAttribute(), _
System.ComponentModel.DesignerCategoryAttribute("code"), _
System.Web.Services.WebServiceBindingAttribute(Name:="IndexSoap", [Namespace]:="http://softwaremaker.net")> _
PublicClass Index
Inherits System.Web.Services.Protocols.SoapHttpClientProtocol

Private HelloLongRunningWorldOperationCompleted As System.Threading.SendOrPostCallback

PublicEvent HelloLongRunningWorldCompleted As HelloLongRunningWorldCompletedEventHandler

<System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://softwaremaker.net/HelloLongRunningWorld", RequestNamespace:="http://softwaremaker.net", ResponseNamespace:="http://softwaremaker.net", Use:=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle:=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)> _
PublicFunction HelloLongRunningWorld() AsString
Dim results() AsObject=Me.Invoke("HelloLongRunningWorld", NewObject(-1) {})
ReturnCType(results(0), String)
EndFunction

PublicFunction BeginHelloLongRunningWorld(ByVal callback As System.AsyncCallback, ByVal asyncState AsObject) As System.IAsyncResult
ReturnMe.BeginInvoke("HelloLongRunningWorld", NewObject(-1) {}, callback, asyncState)
EndFunction

PublicFunction EndHelloLongRunningWorld(ByVal asyncResult As System.IAsyncResult) AsString
Dim results() AsObject=Me.EndInvoke(asyncResult)
ReturnCType(results(0), String)
EndFunction

PublicOverloadsSub HelloLongRunningWorldAsync()
Me.HelloLongRunningWorldAsync(Nothing)
EndSub

PublicOverloadsSub HelloLongRunningWorldAsync(ByVal userState AsObject)
If (Me.HelloLongRunningWorldOperationCompleted IsNothing) Then
Me.HelloLongRunningWorldOperationCompleted =AddressOfMe.OnHelloLongRunningWorldOperationCompleted
EndIf
Me.InvokeAsync("HelloLongRunningWorld", NewObject(-1) {}, Me.HelloLongRunningWorldOperationCompleted, userState)
EndSub

PrivateSub OnHelloLongRunningWorldOperationCompleted(ByVal arg AsObject)
If (Not (Me.HelloLongRunningWorldCompletedEvent) IsNothing) Then
Dim invokeArgs As System.Web.Services.Protocols.InvokeCompletedEventArgs =CType(arg, System.Web.Services.Protocols.InvokeCompletedEventArgs)
RaiseEvent HelloLongRunningWorldCompleted(Me, New HelloLongRunningWorldCompletedEventArgs(invokeArgs.Results, invokeArgs.Error, invokeArgs.Cancelled, invokeArgs.UserState))
EndIf
EndSub

PublicShadowsSub CancelAsync(ByVal userState AsObject)
MyBase.CancelAsync(userState)
EndSub
EndClass

PublicDelegateSub HelloLongRunningWorldCompletedEventHandler(ByVal sender AsObject, ByVal args As HelloLongRunningWorldCompletedEventArgs)

PublicClass HelloLongRunningWorldCompletedEventArgs
Inherits System.ComponentModel.AsyncCompletedEventArgs

Private results() AsObject

FriendSubNew(ByVal results() AsObject, ByVal exception As System.Exception, ByVal cancelled AsBoolean, ByVal userState AsObject)
MyBase.New(exception, cancelled, userState)
Me.results = results
EndSub

PublicReadOnlyProperty Result() AsString
Get
Me.RaiseExceptionIfNecessary()
ReturnCType(Me.results(0), String)
EndGet
EndProperty
EndClass

So if you are going to use an Event-Based model to invoke a Service asynchronously, you would so something like this [simplistically, of course]

The AddHandler method provides some sort of a dynamic hook-up to basically link an object's event to a method that should be called to handle that event. This model is used very much in Windows VB/.NET programming with keywords like Handles, RaiseEvent, Event, etc.

For example...

Class Man
PublicEvent SawSomethingInteresting(s asObject)

PublicSub SeeSomething(s asObject)
IfTypeOfObjectIs PrettyWoman
RaiseEvent SawSomethingInteresting(s)
Endif
EndSub
EndClass

Class Main
Dim M as Man =new Man
AddHandler M.SawSomethingInteresting, AddressOf OnSeeingSomethingInteresting

M.SeeSomething(PrettyWoman)

PublicSub OnSeeingSomethingInteresting(s asObject)
Throat.VoiceBox.MakeFunnyNoises
EndSub
EndClass

Another good thing about AddHandlers is that it offers a dynamic Link-Up to Function Pointers at Runtime. All those people who have, at some point in time, programmed custom, dynamic controls at runtime will know the power of AddHandlers. You can specify as many AddHandlers as you like, and the events raised are sent to all handlers in a serial, synchronous process. This means that the event is not delivered to the next handler until the current handler is completed. So, while its powerful, use it with proper care.

Moving on...

• proxy.HelloLongRunningWorldCompleted is of type HelloLongRunningWorldCompletedEventHandler with a signature of 2 parameters (object and HelloLongRunningWorldCompletedEventArgs) declared as an event. With the hookup to any CallBack Method (CallMeBack), this also means that CallMeBack must have the same signatures or it will NOT compile. This is one of the great type-safe features that Delegates offer in .NET.
• proxy.HelloLongRunningWorldAsync is an overloaded method that basically calls InvokeAsync of the base SoapHttpClientProtocol class which calls the method “HelloLongRunningWorld” asynchronously.

OverLoads Protected Function InvokeAsync( _
 ByVal methodName As String, _
 ByVal parameters() As Object, _
 ByVal callback As SendOrPostCallback, _
 ByVal userState As Object _
) As Void

where...

1. methodName = The name of the method to invoke
2. parameters = The parameters to pass to the method.
3. callback = The delegate called when the method invocation has completed.
4. userState = An object used to pass state information into the callback delegate.

In our case of the client proxy stubs,

Me.InvokeAsync("HelloLongRunningWorld", New Object(-1) {}, Me.HelloLongRunningWorldOperationCompleted, userState)

1. methodName = HelloLongRunningWorld. This is self-explanatory
2. parameters = New Object(-1) {}. This is how parameters are passed in .NET SOAP Calls.
3. callback = HelloLongRunningWorldOperationCompleted which is of type System.Threading.SendOrPostCallback. This is a new delegate in .NET 2.0 and it represents a callback method that you want to execute when a message is to be dispatched to a synchronization context. Create the delegate by passing your callback method to the SendOrPostCallback constructor. The function pointer in this case is the AddressOf Me.OnHelloLongRunningWorldOperationCompleted.

• The OnHelloLongRunningWorldOperationCompleted method is the callback method I want to execute in my proxy class when the message is ready to be dispatched. This will then invoke the all-too-familiar RaiseEvent method. This method also instantiates yet another new class in .NET 2.0 called InvokeCompletedEventArgs. It represents the results of an asynchronously invoked web method. I wont go into much details about this here.
• The RaiseEvent keyword, like I have mentioned earlier, sends the event to all Event Handlers registered with the AddHandler keyword. In this case, it will be a callback to the delegate (HelloLongRunningWorldCompletedEventHandler) which has a function pointer to the CallMeBack Method.
• CallMeBack will produce a Messagebox with the results once the results are dispatched and the asychronous callback is completed.

There, doesnt that look so much better, neater and definitely much more intuitive ? Anyways, the main chunk of code is now done at the client proxy stubs which is automatically generated by WSDL v2.0.40607.16. It is therefore fair enough to assume that the inner plumbings is and should be abstracted away from the business developers whose job is to write lesser code and create more value and productivity. The asynchronous programming of Services had just gotten so much more simplified !

I believe that .NET developers will adapt to this new Event-Based Asynchronous programming model in ASMX v2.0 easily and will show a preference for it over the slightly clunkier Begin<YourMethodNameHere> and End<YourMethodNameHere> model of delegates and asynchronous callbacks.

This blog post is replicated from a previous blog here.

Http.sys is a kernel-mode networking component of Windows and is baked into the base OS of Windows Server 2003 and now, Windows XP SP2. See here for more information.

According to Don Box here, the thinking is that it's better to have one hardened implementation in the base OS than 4-5 one-off implementations in different products/technologies. Old-timers may recall that early builds of the .NET Framework installed HTTP.SYS in order to get .NET Remoting to work with HTTP (I think it was called the COM+ web server). The fact that we had to ship a one-off HTTP server implementation in .NET Remoting was an unfortunate byproduct of HTTP.SYS not having a ship vehicle that was close to .NET V1. Hopefully making HTTP.SYS part of the base OS will keep others from going down the same path.

VS2005 now comes with a Managed Framework for Http.sys (HttpListener). Even though it was possible to host ASPX and ASMX in any managed process (WinForms, ConsoleApps, WindowsServices...) since .NET v1.0, the HttpListener class that comes with VS2005 makes it a lot easier.

ASP.NET Cassini Web Server is an example of a Windows Application hosting ASP.NET and is used throughout ASP.NET v2.0. It can run on your desktop without the use of IIS.

I will show some very simplistic examples of the how-tos in hosting HTTP Processes in a Console Application using a Console Application in .NET 2.0. In this case, I have built a simple IIS-less Web Server that can churn out Web Pages, SOAP and even SOAP that is WS-* Compliant using Web Services Enhancements (WSE) 2.0 !!!

You can find information related to the above from my previous blog post here. Do take note that the codes show there are for test and demo purposes only. There needs to be major re-work and re-factoring before it can even be considered usable.

On another node, Aaron Skonnard has just published an article here that gives a detailed explanation on the above. Do check it out.

My previous blogs on Visual Studio 2005