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).

Let's face it traditional web apps are pretty prosaic. Even business users are demanding additional interactivity because it saves them time. XAML makes is much easier to manage user interaction. This frees the developers to provide user interface features that they just don't dare do with traditional web applications; the overhead of debugging/maintaining javascript/DHTML interaction is just too scary.

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.

I have seen the future and it is XAML

It seems very clear now that a pure Service Oriented Architecture is emerging that will start to replace the existing platform-specific architectures in place today. It will not matter whether the platform is J2EE, .Net or Mainframe; all should be able to consume and provide services reasonably interoperably.

Golden age of SOA? SOA will start to add capabilities that were not possible in a platform independent manner before. Capabilities like 2PC transactions; long-running compensating transactions; reliable messaging; transfer of large binary data (MTOM); message-based, federated security; stateful services (process orchestration); and much more. It is good to know that all major vendors Microsoft, IBM, BEA, Sun and even open source Axis are targeting the same feature set and are largely on track to deliver the advanced features in the near future (if not already). Add to this the recently re-energized Web Services Interoperability organization with the new Basic Profile and Reliable Secure Profile and we might just be on the cusp of the golden age of SOA.

But what about the user interface (UI)? There are several technologies that can directly take advantage of XML web services; portlets; Java clients; .Net Smart Clients; Microsoft Office clients; AJAX web clients; xForms; InfoPath; SVG; and Flash come to mind immediately. And I am sure there are many more. But now there is a new kid on the block called XAML (pronounced zamel). I recently had to chance to take a deep dive into XAML and came away duly impressed.

XAML is from Microsoft - part of the Windows Presentation Foundation. At its heart XAML is an XML language for declaratively specifying very rich user interfaces; so much so that even animation of UI components can be specified declaratively in XAML. Another key feature is XAML's declarative, two-way data binding to an XML or object data source. The combined effect of these two features makes XAML a very potent force.

It is fair to say that XAML may not be accepted for general consumer-facing web applications any time soon; AJAX will probably continue to rule in that domain for a while. This is because XAML requires a Microsoft-specific implementation at this time. However, for internal web apps where the desktop standard is Microsoft Windows and Internet Explorer (easily more than 90% of large organizations today) XAML makes perfect sense as a replacement of existing UI technologies (such as JSP, ASP, Flash, etc).

In a series of upcoming posts, I will examine XAML and try to establish that companies that 'get' XAML and are able to harness it well, will stand to gain a considerable competitive advantage over those that don't.

BCS Presented at AutoTech 2005

I have not posted to this blog for a while but BCS work has been progressing all along albiet at a slow pace. I just have been really busy helping with the adoption of intra-enterprise Web Services.

I had the chance to present BCS at AutoTech 2005 -- the premier conference for the North American automotive supply chain.

The MagicDraw plug-in -- a reference implementation of BCS -- now generates BPEL from Business Collaboration Diagrams. I hope to update it soon to also generate WSDL and PartnerLink types. I plan to make the plug-in and the source code generally available towards the end of the year. Update: The source code is now functional but I may have to use it for a thesis so I am going to hold off publishing it for a while.

Technocarti Tags
Business Collaboration
eCommerce
SOA
Web Services

BCS-to-BPEL Transformation

I have finally finshed a strawman of the transformation from a BCS Business Collaboration Diagram (BCD) to abstract BPEL (as noted earlier, BPEL is generated for each swimlane in a BCD).

The transformation is documented as a set of UML State Diagrams embedded in a PowerPoint presentation.

In the coming weeks, I plan to update the MagicDraw (tm) BCS plugin to generate BPEL from BCD in the manner documented.

Specifying Business Collaborations over Web Services

The WS* stack has BPEL that provides the description of a process controlled by a single participant. This does not really address how to specify business collaborations -- multiple coordinated processes.

At AIAG (Automotive Industry Action Group) we are working on a Model-Driven approach to Web Services collaborations. It is a work in progress but seems to provide some of the missing pieces. We call it Business Collaboration Specification (click the link to see a primer PowerPoint)