Battle of the RIA platform

Adobe used to be the undisputed leader in the Rich Internet Applications (RIA) space until Microsoft entered the market with SilverLight. Today Adobe has just announced the release of Adobe AIR and Flex 3 products and with Microsoft soon to release SilverLight 2.0 the RIA battle is heating up between the two rivals. How will these 2 vendors woe customers into using their respective RIA technologies?

The Adobe story:
- Proven technology, Adobe has their flash plug in practically every browser that’s connected to the internet.
- Cross platform and browser capability
- Appeal: Adobe as a company has several “designer” – hence the product is by designer for designers
- Their products have dominated the RIA market and this release strengthens the capabilities of existing products.

The Microsoft Story:
- SilverLight 1.0 was a big step for Microsoft, however SilverLight doesn’t enjoy the level of installation base as Adobe
- SilverLight is currently supported by IE and Safari (planned support for FireFox), Microsoft has tied up with Novel to develop plugins for other browsers. SilverLight is leveraging only a subset of .NET - .NET 4.0 “Profiles” will be driven by requirements from SilverLight
- Appeal: Microsoft is essentially a developer company – and hence with SilverLight support for .NET will appeal to many of the .NET developers. Microsoft has done a good job with the Expressions suite and will attract several designer as well with the product. Microsoft with support for ASP.NET AJAX, SilverLight, XBAP and full blown WPF has a compelling user interface story for a wide variety of user interfaces all supporting .NET framework.

Microsoft to announce SilverLight 2.0 in a couple of days time during Mix08 should be interesting space to watch.

Microsoft BI tops Gartner 2008 BI Platforms list

Many a times we have customers coming in during architectural design session and strategy briefings questioning the capabilities of Microsofts BI stack, and often time they would have done some internal investigation on the other BI platforms and would cite examples of how other platforms have been rated better by leading market analysts like Gartner, IDC, Forester etc. From a TOC point of view the MS BI stack wins hands down but the question has always been on the ability to execute successfully on the MS BI stack – Gartner in the 2008 BI platform has ranked Microsofts BI on top of other vendor products. Microsofts already had a robust data warehousing strategy with the SQL Server stack but now has a compelling case for analytics with the integration of Performance Point Server (PPS) 2007 and Microsoft Office SharePoint Server (MOSS).

Microsofts ability to take a specialized product and commoditize it by providing it at a very low cost is nothing new, it has been doing so in the past and appears to have got it going for BI, recent consolidation of top raking BI vendors such as Business Objects -> SAP and Cognos -> IBM is the reaction to the onslaught of the MS BI juggernaut.

When Microsoft releases SQL Server 2008 it should provide improved BI capabilities to an already compelling BI platform. All said and done the MS BI stack does provide a robust and scalable BI platform however in our experience we have seen two limitations in the current MS BI stack
- The SQL Server Integration Services (SSIS), Microsofts ETL product though definitely an improvement over its predecessor DTS still is cumbersome and difficult to implement compared to other products in the market like Business Objects Data Integrator and Informatica.
- Performance Point Server 2007 currently is suitable only for Intranet BI scenarios its possibly not the best choice for hosted BI scenario. Microsoft has not done a good job of integrating the procured ProClarity product into PPS.

Hopefully the next version of the BI products would fix the above limitations.

Your next Language++

Was in a discussion with a couple of technology consultants for the implementation of an upcoming software product, the discussion soon turned into a heated debate over the technology stack to be implemented, the debate soon moved over to choosing a language for implementation (technology consultants can get awfully spirited in these discussions :) ). No prize for guessing - the debate was between choosing .NET+C# vs. Ruby on Rails. I admit I appreciate the Rails framework and often wish we had similar capabilities in C#/VB.NET. Ruby and other dynamic languages like Python can be used to build applications that are incredibly dynamic in terms of runtime polymorphism however it comes at a price – performance.

The real question is if you are already proficient in a software language be it Java/C#/VB.NET etc (and hopefully not extremely religious about it) what would be the other language you need to pick up? Ruby seems to be on every ones radar. Is it the obvious choice for your next language?

Lets take a step back and look at languages in general. Languages can be split into 3 broad categories
- Object Oriented Languages
- Functional Programming Languages
- Procedural Languages

The vast majority of all the software built today are developed using general purpose object oriented languages like Java and C#. Ruby is still a general purpose object oriented language with dynamic/runtime capabilities. Several of these capabilities are now being introduced in the C# language (will reserve that for another post). So that’s the story on the object oriented language side. Nothing significant seems to be happening on the procedural language. But there is some excitement brewing up in the functional programming world.
Why consider a functional programming language? Interestingly some of the new features bleeding into the C# languages such as LINQ, type inferencing (ie using var in C#) etc is heavily influenced by functional programming. OO languages basically focus on state and behavior where as FP minimize or avoids (particularly in case of purely FP languages) state and mutability of data - due to the way FP handle mutability of data via functional operations it FP suitable to execute tasks in parallel thus providing a highly scalable solution to problems that are iterative in nature, Functional programming languages are especially suited for multi-core systems . Companies such as Google have I implemented their search infrastructure on top of FP. A full description of FP is beyond the scope of this blog entry however FPs has its place and in some scenarios may be optimal for use. The question now is which FP language to learn? Microsoft has been working on F# which is a FP language and is also a multi-paradigm language – ie it has implemented several features that are common to both functional languages (largely influenced by ML and OCaml languages) as well as object oriented languages (LISP for instance is also multi paradigm in nature). F# is a good choice since it implemented on the .NET framework. I.e. we can build components that are easily modeled using functional programming style in F# and import those components in C# and vice versa. F#s integration into VS.NET 2005 is a strong indication of Microsofts commitment to the language (unfortunately the addin for VS2008 is still not available).In the future we should can see wide spread adoption of Microsofts TPL and FPX frameworks along with F# libraries.

Will FP finally move from academic circles to commerical application? And how will F# fare ?Only time will tell. Meanwhile I put my bet on F#.

What do you think? What will be your next Language++?

Sun in a language soup

For over a decade Sun has been branding Java as the programming language of choice and building new capabilities around the Java framework, interestingly their approach has been to position the language (Java) along with the framework (Java Enterprise Edition, Java Standard Edition etc). Now Sun is contemplating something the .NET framework had since its inception - support for multiple languages. With languages such as Ruby gaining significant adoption by the developer community neither Microsoft or Sun could back away from adopting Ruby – for Microsoft the implementation of another language like Ruby (IronRuby in this case) would be seamless since they would primarily have to make their implementation of ruby Common Language Infrastructure (CLI) compliant. From a technical perspective Sun would not have a significant challenge implementing Ruby (ie the Da Vinci Machine Project) but what would be the message they are sending to the developer community? Will they reposition the JVM? Will it be rebranded? What will happen to all those acronyms in the Java community (JSP, JSF, JNI, JNDI, EJB etc - and 100s of other popular acronyms prefixed with the 'J' moniker), for that matter you cant call it the Java community can you ? J . Wow think about it a community focusing on a platform unified by a single language – now possibly repositioning the framework in another language(s). Chaos.

Should be interesting to see how Sun and the community pulls it off.

Multicores, the developer dilemma and Microsoft PFX

Thanks to Moores law developers never had to worry about how their application would perform with newer processors, with every newer-faster processor in the market their application 'automagically' just ran faster. This is all set to change Moores law will no longer apply to processors - adding more transistors to a processor is not feasible anymore since doing so is heating up the processor hence most of the processor manufacturers like Intel, AMD and IBM are going for multi core processor architecture. ie now individual processors will not have radically improved performance, high performance can be acheived by leveraging the multicores of the processor. Leveraging different cores on the processor is a challenge developers never had to face in the past.

So how do we write code that take advantage of multicores? Fortunately application servers like Microsoft IIS and SQL Server already ship with support for multicore but how can our applications leverage it? Relying on the developers to write code optimized for multicore would be too much to ask, the good folks at Microsoft are working on a framework (for managed code) that can greatly enhance developer productivity when targeting multicore systems. The framework is called the .NET PFX , the December 2007 CTP can be downloaded from here.
What do you do when you have an 8 core server around at your disposal … run PFX of course :) … beats running it off my dual core laptop. Have created a simple project that simulates computation work via 2 for loops, later the outer for loop was changed to a Parallel.For (new set of features in the PFX available in the System.Threading namespace)

The results are as follows:

When running the basic nested loop the overall operation takes 11792 milliseconds and as can be seen in the figure below only one core is being leveraged (behind the scene only one thread is being used)

When the same code is run using the PFX the same set of operations take 1746 milliseconds ie almost 1/10th the time taken in the previous case and as can be seen in the figure multiple cores are being used to complete the task (behind the scene multiple threads are being used)

This post demonstrates a simple case where the PFX can be used, in the future post we will take a look at using PFX (and PLINQ) to build more complex applications.

Are stored procedures better than direct queries?

This blog is to address an age old debate: Are stored procedures better than direct queries.

Sure from a manageability and granular security control standpoint stored procedures offer much more capabilities but the real question is if direct queries (Ad hoc queries) can scale as well as a stored procedures.

Most of the forum discussions and blog entries end in a stalemate - SQL Server is now optimized for ad hoc queries as well it creates a plan cache for the query and parameterizes the query so that i can be used again when a similar query is executed (i.e. both queries should be exactly the same even an additional whitespace or change in case will lead to the query plan not being reused). However there is proof that stored procedures consume less memory and hence improve overall scalability of the application.

To see this in action I have created a simple scenario with an Employee table having columns empId and EmpName. This file contains the scripts that I have used for creating the schema and inserting 10 rows of test data. The script also contains 10 direct SELECT statements and 10 calls to a stored procedure which contains a simple SELECT statement. Clear the procedure cache before executing the script. Once the script is executed check the DMV sys.dm_exec_cached_plans using the following script

select text,refcounts, usecounts, cacheobjtype, objtype, size_in_bytes, memory_object_address from sys.dm_exec_cached_plans qs cross apply sys.dm_exec_sql_text(plan_handle) ORDER BY UseCounts DESC

The resultset for the above script is:

Now whats interesting in the resultset is that the stored procedure plan was compiled and reused 10 time but in case of the ad hoc queries the plan was compiled and is being reused (ie 10 times) however SQL Server is also tracking the queries issued separately and memory is being consumed for these individual queries separately, and as the column memory_object_address indicate memory is being allocated separately for different queries it not reusing the same memory. Another way to see this behavior is to view the bpool_committed column in the sys.dm_os_sys_info DMV, note that SQL Server will under memory pressure throw things out of the buffer when ever required so using direct queries are not totally evil but as indicated above do not scale as well as stored procedures.

Hence Recommendation: Go with stored procedures :)