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.

One of the topics presented during the Architecture Track in the just-concluded Microsoft TechED South East Asia 2006 was done by IASA.

It was done via a very interactive session with the floor questioning the panel from the IASA Malaysian chapter about the value of being an architect and topics of the like.

One of the questions from the floor was: "Do you believe that architects should be writing code ?"

It seems that 3/4 of the panel members agree. Some even going on bragging that he is still doing it in assembly, C++ language. hmmm ... In the interest of keeping the session on time so that that the attendees can get home on time amidst the KL jams - I kept my mouth shut.

Let me open them now.

Architects shouldnt code. Period. My thoughts. Period. To prevent myself from rambling, which is what I always do when I have a strong opinion on something, let me list them in point forms.

The term "architect" is a very nebulous term. The hype around it with all the wannabees printing it in bold font on their cards out there (I know a couple of them in Singapore who does them with no shame), who have no idea what is the difference between horizontal and vertical scaling, doesnt make it any better. For better or worse, I only believe in one type - and that is the all-emcompassing solution architect.

Afterall, aint what all customers want is a solution ? Do you think they really care what is underneath the solution more than that this solution works well, is kept within their budget, perform effectively and efficiently within the constraints of their environment ? Therefore, in this context, I will speak in the context of Solution Architects.

• To those ppl who said that "How can someone who never writes a line of code be responsible for how that code will be written? ", again, I am talking about a solution architect. In any case, an architect can code, sing, dance before, for all I care. They shouldnt be doing it in their role as solution architects now. Read on.

• In the past, code influenced architecture. The limitations of written-code in a chosen-platform in a defined-era is the damning evidence of the limitation of the architecture. VB3 anyone ?

• Biasedness based on preference. A solution architect that has a decade long experience in writing code is usually one that doesnt see the other side of the fence, doesnt know that there are better solutions and worst - refuse to want to see it. Most of the people in this category are usually skilled in one platform over the other and it is very hard for people like that to sit down and analyze a problem without a pre-conceived notion in mind in a very neutral manner. Because of this, the likely solution they are going to propose will have the same limitations of the platform they have been so comfortable with. I dont question the depth. Where is the breadth ? These guys should remain what they are good in and be experts in their domains and probably be paid better than a solution architect. For those who argue that they are equally well-versed in both sides of the fence - Good for you. Stay there. It is very likely you are drawing a lot more than an architect. If you are not, you just need to sell yourself better.

• It is all about the business. Solution Architects bridge the gap between (the returns of) the business with the (returns of) technology. So, yes, they should be just as apt with the Finanical Calculator as much as an Integrated Development Environment or a Installation Panel or Console. They understand the entire depreciation cycle of an enterprise solution much better than the differences between a thread and a process. So yes, the higher the level the language they used to code in (I am talking about 4GL), the better. Bragging how much you still do your work today in First or Second Level Programming Lanaguages doesnt do you any good. In fact, it makes you look bad. It shows the lack of touch you have with your business, how it is run, what are the constraints and the entire business and revenue model. Writing performance drivers, assemblers, kernels, runtimes has nothing to do with a company's business model in a world where Moore's Law still rules.

It is all about the business, still.

Apache Axis2/C version 0.93 is released. This should please the REST camp and highlights the momentum of how REST can be implemented in Web Services. If you are in KL next week, I will be briefly touching base on the REST-vs-SOAP style of implementing Web Services.

Key Features

1. AXIOM, an XML object model optimized for SOAP 1.1/1.2 Messages.
   This has complete XML infoset support.
2. Support for one-way messaging (In-Only) and request response
   messaging (In-Out)
3. Description hierarchy (configuration, service groups, services,
   operations and messages)
4. Directory based deployment model
5. Archive based deployment model
6. Context hierarchy (corresponding contexts to map to each level of
   description hierarchy)
7. Raw XML message receiver
8. Module architecture, mechanism to extend the SOAP processing model
9. Module version support
10. Transports supports: HTTP\
    1. Both simple axis server and Apache2 httpd module for server side
    2. Client transport with ability to enable SSL support
11. Service client and operation client APIs
12. REST support (HTTP POST case)
13. WS-Addressing, both the submission (2004/08) and final (2005/08) versions
14. MTOM/XOP support
15. Code generation tool for stub and skeleton generation for a given
    WSDL (based on Java tool)
    1. Axis Data Binding (ADB) support
16. Security module with UsernameToken support
17. REST support (HTTP GET case) - New
18. Dynamic invocation support (based on XML schema and WSDL
    implementations) - New

Major Changes Since Last Release

1. REST support for HTTP GET case
2. XML Schema implementation
3. Woden/C implementation that supports both WSDL 1.1 and WSDL 2.0
4. Dynamic client invocation (given a WSDL, consume services dynamically)
5. Numerous improvements to API and API documentation
6. Many bug fixes, especially, many paths of execution previously untouched were tested along with Sandesha2/C implementation

Download the above release here.

I cannot help but grin when I found out the next Crypto API (CAPI) - or termed - Crypto NextGen (CNG) and the suite it encompasses will be all included in Microsoft Windows Vista.

This article says it all. Elliptical Curves Cryptography (ECC) should definitely be there (and is) when the Base Smart Card Cryptographic Service Provider (Base CSP) is there as well.

It will be a long post to explain why the industry is adopting ECC and slowly adopting it and making it the cryptographic algorithm of choice. If you do understand the key concepts of prime factoring behind the concepts of Public-Private (or Asymmetric) Key Cryptography and the constraints of it moving forward into the future and the proliferation of mobile embedded devices, these 2 diagrams should suffice.

Doesnt that give you a hint of where we are going with computing processing power and where it may be next time ?

This popped into my inbox a while ago ...

Contests like this are just great. Not only are you receiving money (if you win... Who cares, even if you dont, a digital mutation of your idea may still evolve to a sellable one), you are competing with the best to generate a innovative, marketable, secured and (hopefully) usable product. The byproduct derived from the entire process would be similar to a mini-version of an RFC. Bad and unsecured ones would have been shot down and the good ones could be made better with a few ingenious tweaks.

Now only if I can find 25.5 hours in any given day ...

Blasphemy ...

It is finally published. After many, many, and I mean, many months of paying the process tax for this piece, it is finally LIVE !

I started this piece with the first ever March 2005 CTP of Windows Communication Foundation (WCF, previously - Indigo) and I went through so many port demos and edit document cycles its so unbelievably painful ...

But it is really good to see this in online form and shape.

I started with this idea even though MSFT Corp has explicity stated that it will not support any form of interoperability between WSE 2.0 and WCF, even though it is "theoretically possible to develop Web services using WSE 2.0 in such a way that they can interoperate with WSE 3.0 (and WCF) by using only a reduced set of specifications"

More importantly, the main reason for the motivation to write such a piece is written in the article itself and I quote:

[BEGIN QUOTE]

Depending on timing, budget, complexity and a whole host of other requirements, some of these applications will need to be moved and migrated to WSE3.0 and some to WCF. Aaron Skonnard has provided a great resource in his “Service Station” column on MSDN on a brief overview on the migration of WSE 2.0 applications to WSE 3.0 ones. However, as stated in his article, there are some major changes in the programming model and architecture in WSE 3.0 and migrating them from WSE 2.0 may not be trivial.

Another very important factor to take note is while WinFX, and therefore WCF, is available downstream from Windows Vista to Windows 2003 and Windows XP. That is as far down as it goes. There still exists a huge installed base of Windows 2000 Servers out there running on server and data farms and if you need to implement the advanced Web Services stacks on those servers, WSE is still a very important strategy you cannot ignore.

As noted in the above guidelines, even though Microsoft will not guarantee interoperability between WSE 2.0 and WCF, the good news is that there are a few WSE 2.0 common scenarios, which can allow wire-interoperability with WCF. I will illustrate them in the next section...

So, this article will outlined WHAT that reduced set of specifications are and HOW to go about using them.

Many Special Thanks go to Kirill, the Interop PM on WCF, who gave me a couple of tips to get over the port-over humps I had thoughout this piece since last year. And of course, I cannot forget Clemens, who is the catalyst to making this publication happen when he came onboard.

I hope this helps at least someone out there. Enjoy !