XAML Business Case Part I: The Core Advantage
What is the core business case for XAML? Why should companies choose XAML over existing, well-established user interface technologies? In this post I will try to answer these questions.
Note: This post is part of a series of posts on XAML. Please see XAML Contextual Post for an oversight.
Disclaimer: XAML only makes sense for companies that have already standardized on Microsoft Windows and Internet Explorer for the desktop. I would not recommend XAML for general public facing web sites at this time. However MS is already beta testing Windows Presentation Foundation Everyplace which will make XAML cross-platform in terms of browsers and operating systems. This could make XAML as common as say 'Flash' and eventually make it suitable for consumer-facing, Internet web applications.
Claim #1: All else being equal, XAML will allow developers to be substantially more productive for developing Web Applications of equivalent UI functionality than comparable technologies such JSP/JSF, ASP (with or without AJAX).
I support this claim with the following:
a) 'Super' Rich Clients
XAML allows one to easily build super rich clients which are much harder (if not impossible) to build with traditional technologies. Only Macromedia's Flash and SVG seem to match the richness of XAML but none of these are currently widely used for general business applications. Adobe is no longer supporting the SVG plug-in for Internet Explorer (perhaps this has something do to with Adobe now owning Flash).
XAML not only has support for enabling rich user experiences through a flexible set of UI controls; 2D and 3D animation; vector graphics; transformation, scaling and zooming; video; bit-map effects; etc. but also it makes it easy to program with these features.
b) Declarative Layout and Data Binding
The most appealing feature of XAML (for me) is its declarative, XML-based foundation. There is a clear separation between UI, data and business logic. UI layout is mostly done declaratively in the XAML language (although it can also be done programmatically). Even animation and several types of graphic effects can be declaratively defined. So can binding of data to the UI. Data can be either in the form of objects or XML. Input fields can be two-way bound to object/xml properties so that UI changes are automatically propagated to the data source; this further increasing developer productivity. There is enough flexiblity in the data binding features for most needs to be handled declaratively however for complex needs some programming is required. Overall though the amount of work required to build rich UI's is much lower than any other approach that I know of.
Microsoft is also making XAML designers available with the intention of separating the roles of the UI designer from that of the programmer. To fully exploit XAML's capabilities you would need a skilled graphics artist. However, for most business applications even programmers can make use of the designers to quickly mock up UIs that can be then used directly in applications.
c) Deterministic UI Programming Model
By deterministic I mean the following: The programmer has precise control over user interactions because the interactions are handled in a single address space. This contrasts markedly with traditional web applications where UI processing is split over multiple tiers. Elaborate frameworks (such as ASP and Java Server Faces) are helpful (even indispensable) but can't make UI programming as easy as traditional rich client type applications.
Single address space UI programming also makes programs much easier to debug which gives developers greater confidence in providing richer UI features.
All of this is not new; Flash applications, Java applets, .Net Smart Clients and some others offer similar benefits. By itself this feature is not the deal maker for XAML but it is a crucial feature nonetheless; without it XAML would not make the case. Note that XAML applications can be delivered via the browser making them (almost) as easy to deliver and keep up to date as traditional web applications.
Claim #2: Use of XAML will substantially promote the adoption of Service Oriented Architecture
Ok so we have 3-tier applications with the current web application model. This is better than in the past but I find that many applications still have web pages that are tightly coupled to the database. There is not much of a middle tier. Other than good self-discipline there is no 'natural' factors promoting a proper 3-tier architecture.
The de-facto distributed computing model with XAML applications is to use Web Services for data access. This naturally forces a service-oriented middle tier. The benefits are plentiful; not only does this lead to better discipline and forethought but also to greater modularity and reusability (the holy grail of SOA).
With Windows Communications Foundation (WCF) under the covers XAML applications have one the best platforms for SOA. None of the other technologies (other than .Net Smart Clients) have this level of web services support. It will be a few years before Java catches up on the client side with what comes packaged in the WCF powerhouse right now.
Java on the server side is another story altogether. With the new JAX-WS standard building server-side Web Services is now enormously easier. J2EE vendors are now fairly current with advanced WS* protocols. All of this makes building XAML applications even more appealing as server side platforms are no longer a significant consideration in the decision to use XAML for the UI.
Maybe you are one who is not enamoured of all of this SOA hoopla. Certainly - I think - all the world ever needed was LISP (and I am not alone). However we are where we are and this is not a bad place to be. SOA is here to stay and it only gets better with XAML.