The Thick and Thin of a Paradigm Shift

If I had a time machine :-p, the first thing I'd do would be to go check out the Dinosaurs, alive and in all their spectacular glory. Then, certainly, I'd jump right into the future to see where we are heading with our development tools, platforms and standards :)

A change has already begun. Actually, change is continual in technology; however, change that shifts entire UI development paradigms are more rare. Microsoft's .NET initiative [1] is part of a change that is occurring in current software development paradigms. This change, I believe, supplements the slow, progressive changes that occur to software development paradigms every few years, but the one to come may have a more profound impact than some of the major shifts of the past.  We are at the foothold of the next large step forward in software development, perhaps.

Lines are continually being blurred:

• can execute on heterogeneous systems that support CLI standards [1]
• will be able to execute with a GUI on heterogeneous systems (assuming XAML will be standardized)

• can be formatted and packaged easily
• can be structured; structural information can be shared easily
• can be aggregated with heterogeneous data easily
• can be distributed between heterogeneous systems easily and in a standardized manner

Database management systems

• can handle the workloads of application servers using the same tools and languages
• are becoming more portable and efficient as the ability of hardware scales
• can be programmed against by thinking conceptually, like its entities were designed
• can import and export data from heterogeneous systems based on XML standards

Rich-client applications

• can consume remote services
• can provide public and local web services, and remoting services for distributed communication and collaboration
• can host ASP.NET and a WebBrowser
• can be deployed easily over the web
• can be hosted in an RDBMS, adjacent to the data being used.  Data itself can be pure XML markup, which is natively supported by the RDBMS
• can be presented using markup (WPF, XAML)

I predict that as the ability of hardware scales, rich-client applications, in there entirety, will be service-oriented, data-driven, data-encapsulating, portable, secure, and interactive components that are part of a distributed framework of other rich-client component applications found on LANs and WANs, forming a network of peer-to-peer business intelligence systems.  They'll fit nicely into Microsoft's OS and possibly other third-party OSs (Vista, having built-in support for Peer Name Resolution Protocol (PNRP) and People Near Me (PNM), PeerChannel in WCF [4], and .NET FCL such as for system networking [5] and ClickOnce [6], is only the beginning).

From Thin to Thick

I believe that Microsoft may be trying to secure their place as providers of a rich-client OS and software development platform by slowly spinning the current trends in web development back into rich-client development. This is a good thing for developers and end-users, IMO.  But maybe I'm giving too much credit to Microsoft by assuming that this progression was intentional :)

Web development and standards are hard to create and enforce for a few reasons:

• Hypertext markup, especially dynamic markup that includes scripting support, is complex
• There are many browsers and each have their own implementations of complex presentation standards, which have problems of their own
• Website developers tend to value aesthetics over ease of use and intuitive behavior and functionality
• Website design is largely proprietary since standards only go as far as compatibility, not visual appeal
• Because of the point above, visual designs frequently change; design trends under the guise of standardization

Websites are not ideal for business intelligence applications because

• they have limited runtime ability due to non-existent scripting security standards
• they have limited runtime ability due to inefficient languages and platforms (e.g., scripting)
• they do not provide a rich, real-time user interface
• they require network connectivity

Standardization

Totalitarianism isn't something I'm too fond of in government, but in software development and practice I'd prefer if the company creating the tools that I use would also enforce standards for using them. Standards ease interoperability, increasing the value of my applications. Interoperability relates to the new trend in software development, SOA (Service Oriented Architecture) since services are commonly distributed among heterogeneous systems (e.g., Web Services).  So long as the standards are good ones, I favor them to no standards at all.

Microsoft produces and enforces standards in several ways:

• The release of a new OS
• The construction of new APIs
• The authoring of documentation for standards and guidance
• The creation of new training material and certifications for developers
• Submission for standardization to ISO, ANSI and ECMA
• Microsoft Open Specification Promise (OSP) [7]
• Deprecation of legacy tools and support

And the community accepts shifts in software development paradigms, tools and support if Microsoft (and usually when Microsoft) proves that the new technology and standards will make development easier and provide a better overall experience for end-users.  Out pours new books, seminars, user groups, newsgroups, training kits, on-line training, on-site training, certifications and standardization - and we're off to a new era in software development.

These shifts are common; a natural progression as new technology becomes available as a response to the demands of end-users and developers, but it's worth noting too that some technology doesn't survive long (DirectAnimation comes to mind).

So it seems that sometime in the future, hardware permitting, there will be a conversion from web programming trends into a standardized, distributed, service-oriented, conceptually-architected, "packaged", rich-client programming paradigm that spans operating systems from different vendors, with Microsoft in the driver's seat.

Buckle your seat belts :)

--
Appendix

¹[M]ultiple high-level languages may be executed in different system environments [1]
²Sql Server 2005 Express is on the foreground of data-encapsulation within rich-client programs by providing a pluggable data model that can execute .NET Framework code. If standardized, or if some Sql Server Express edition in the future becomes standard with a Microsoft OS installation, fully encapsulated rich-client applications will be distributable without the need for the classic separation of data tier, middleware and presentation (disregarding OOP design patterns and techniques, of course).

--
References

[1] The Common Language Runtime (CLR)
http://msdn2.microsoft.com/en-us/library/aa497266.aspx

[2] Understanding Enterprise Platforms
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/jdni_ch02.asp

[3] The ADO.NET Entity Framework Overview
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/ADONETEnFrmOvw.asp

[4] Peer To Peer, Harness The Power Of P2P Communication In Windows Vista And WCF
http://msdn.microsoft.com/msdnmag/issues/06/10/PeerToPeer/default.aspx

[5] Windows Vista Networking for Developers (September 1, 2006)
http://msdn.microsoft.com/chats/transcripts/windows/06_0901_msdn_vista.aspx

[6] Windows Vista § Development technologies
http://en.wikipedia.org/wiki/Windows_Vista

[7] Microsoft Open Specification Promise
http://www.microsoft.com/interop/osp/default.mspx

As always, I'd love to hear from anyone that has something to say about this post.  Drop me a comment.