Methodology

The topic of Methodology is a recurring topic with current debate focusing on Agile versus traditional approaches. Firstly, what is a methodology?

A definition from Wikipedia is "the analysis of the principles of methods, rules, and postulates employed by a discipline". What does this mean?

In common use within IT, the concept usually means the set of activities, roles, artefacts, and techniques associated with the Software Development Lifecycle (SDLC). Emphasis is usually placed on the Work Breakdown Structure (WBS) – the set of tasks and assignment of tasks to roles, required to deliver a set of outcomes. The debate on Agile versus traditional approaches often focuses on the degree of formalism of the WBS and controls required to deliver the best outcomes. Agile approaches favour individuals and interactions over process and tools. (See the Agile Manifesto.) Overly prescriptive Work Breakdown Structures in a given project context can add significant time and expense to a project without necessarily helping experienced professionals. As a consequence, some development organisations prefer the use of checklists as an aid to professionals to ensure that tasks and dependencies are not forgotten. A pragmatic approach tailors the level of formalism for a given project context including factors such as contractual requirements, team experience and distribution, project size, etc.

This is all good; however, a dimension of methodology that is often glossed over is the content. Systems development is primarily concerned with progressive refinement of a model. The process starts with a model of the business - strategies, objectives, processes, roles, and requirements, which is refined to a model of the system – use cases, data, objects, workflow, etc. The system model is refined to increasing levels of granularity until code is produced, which is still an abstraction above the machine processing instructions.

The efficiency and effectiveness of the Software Development Lifecycle is driven by how quickly the model can be refined with a minimum amount of activity that is not directly related to model refinement, and while still maintaining a high degree of fidelity with the business environment and its needs. Yet how the model is exactly refined from analysis to design to implementation is a mystery to many developers, let alone project managers. This is where a methodology can play a key role in explaining how the models are refined and the linkages between project artefacts to ensure the right information is being captured and produced at each stage of the lifecycle.

A failing that I see with large methodologies such as the Rational Unified Process (RUP) is that because it attempts to support a wide range of project types, it describes a large set of artefacts, but doesn’t describe well how the artefacts support each other; e.g. how does a set of use cases transition to a set of service interface designs.

A useful methodology which supports both novice and experienced developers alike is one that describe the linkages and transitions between the minimum set of artefacts for a given project type. Novice developers benefit from explanations of how to produce a required artefact instead of a table of contents. Experienced developers benefit from agreeing how they will interface with each other to ensure convergence on a common solution without being told "how to suck eggs."

In later articles I will describe an approach I use to transition analysis models to design models.

Usability

As I was hiking on my recent holiday trying to give my mind a rest, it occurred to me how easy it is to become fixated; trying to improve within a narrow band but lose the plot. I think this happens within the IT industry frequently. For example, Usability becomes fixated on user interfaces (screens). It seems as if most analysts automatically assume to convert paper form shuffling to electronic form shuffling. Isn't a system more usable if there is less of it to have to use.

Can the forms be removed altogether? Customers enter their details on-line once. Systems are integrated to remove data re-entry. Rules engines are used to process information. Perhaps the system simply notifies someone by email if there is an exception with pre-meditated choices of action. An Information Architect should first attempt to remove all visible traces of the system before starting to design any user interface.

Secondly, the WIMP (Windows, Icons, Mouse, Pull-down menus) style dominates current user interface design. Xerox first developed the familiar user interface adopted first by Macs and then Microsoft with Windows. However, the design was developed with reviewing documents on-line in mind. Xerox wanted a more intuitive user interface for users to reviews documents WYSIWYG (What You See Is What You Get) before printing to paper. However, we already know that use of a mouse and pull-down menus slows down data entry. Perhaps some other user interface using email or SMS is appropriate for action orientated systems. If you can reduce the number of data entry clerks and people behind a desk then systems can be designed that better support people engaged in face to face interaction.

In the words of Antoinè De Saint-Exupéry, "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."

Ant vs Maven

I've recently moved the build tool of a large multi-project system from Ant to Maven. I liked the concept of Maven, in particular, the ability to declare dependencies on third-party libraries and load them from a shared repository, the ability to work with a hierarchical project structure, and in general, a tool that makes common build tasks simple.

In the end, I'm not sure if a complex build environment can be neatly abstracted from lower level coding or whether Maven is just poorly implemented in parts.

Firstly, the dependency management feature has introduced as many problems as it has saved. I end up downloading more JAR files than I expected since the third party libraries I use have their dependencies which have their dependencies and so on. Some of the libraries in the public repositories don't seem to do a good job of keeping dependencies to a minimum required set. In addition, the same library will be downloaded multiple times as each dependent library specifies a difference version. So the reality is a great deal of time is required to specify exclusions and research the dependency trees of various libraries. Therefore, little time is saved compared with manually downloading only the necessary libraries.

Secondly, doing anything out of the ordinary quickly gets difficult and complex. For example, copying an artifact to a non-default location requires adding and configuring a plugin. Many complex tasks must resort to using the Maven Antrun plugin to run ant tasks (which defeats the purpose of moving from ant) or to writing your own plugin.

Thirdly, many of the plugins are poorly documented and implemented. For example, the Maven Archetype plugin used to create a project template uses Velocity to perform variable substitution in template files. However, if you want to use Velocity template files as part of the project template you can't.

The verdict is I'm sorry I spent a great deal of time moving to Maven. Maven is faster for straightforward projects with a standard compile, test, package and deploy lifecycle. But once you need to automate other tasks, such as generating Hibernate mapping files, or manage a large number of dependencies, Maven quickly starts to become an obstacle rather than an enabler.

Bootstrap Code Generation Framework Released

Development of the Bootstrap Framework started in December 2003 while I had a long wait at an airport. It was born out of frustration that getting applications started took too long and distracted from concentrating on the core business functionality. It also became a personal tool to integrate new technologies, such as Hibernate, to quickly create working applications to better understand how to use the new technologies. The core domain model of an application remains fairly consistent while infrastructure technologies - to persist state to a database, create the user interface, etc, change frequently.

While earlier versions of the framework generated applications using Struts and EJB2, its has evolved to integrate technologies such as the Spring Framework and Hibernate. This first published release uses Spring, Hibernate, and Flex as the front-end in response to a recent presentation I gave at a Flex Users Group and my recent learning to better understand Flex 2 and its integration with Java.

Publishing this first release was also dependent on migrating from Ant to Maven to improve the build of generated applications and management of third-party library dependencies. This was a much bigger task than I had expected.

I am releasing the code under the LGPL license. The intent is to ensure that any improvements to the generator and templates is made available back to the community, while generated applications may be used for commercial applications.

I welcome feedback.

Business Process Management

Introduction

Business Process Management (BPM) is topical but can be a confusing subject since it covers a broad context.

The purpose of this paper is to discuss some of the Use Cases to which BPM is applied, the applicable standards, various architectures, and candidate technologies, to help with a deeper understanding of the subject.

Benefits of BPM

This paper does not focus on the benefits of BPM. At a high level though, a key benefit of BPM is as a tool to help build more adaptable applications that can evolve as business demands change, and to be able to monitor the performance of business processes in real time.

Use Cases

Business Process Management (BPM) appears to be applied to two primary use cases:

· Enterprise Application Integration (EAI)

· Workflow

Workflow, in turn, is often applied at two levels:

· Long running business transaction, often involving more than one system/service;

· Page flow within an application.

EAI is about orchestrating two or more systems/services into a broader process context. (Processes may encompass human input or review, which gets into workflow territory.)

Workflow is about externalising the business processing rules within an application into (typically) a generic state machine representation, so that the rules can be reconfigured over time with minimal disruption to the application. (Workflows may encompass more than one existing application, which gets into EAI territory, or be embedded within an application. The application may be a node in a process orchestration.)

The responsibility for managing workflow typically resides in the Services Tier since this is where transactions are usually managed, interacting with one or more resources including a database.

Page flow is concerned with the logic flow from one screen to the next; as classic example being an on-line purchase “wizard”: review shopping basket, checkout, enter billing details, enter shipping details, enter credit card details, and finally confirm order before processing. The responsibility for managing page flow typically resides in the Presentation Tier.

In each use case, however, there if a ‘flowchart-like’ sequence of activities with if-then-else branches, loops, and exceptions. BPM is in essence defining and managing this flow in such as way that it is not deeply embedded in code and cannot be easily changed. BPM and a Rules Engine often go hand-in-hand since rules govern routing decision within the process flow. (A Rules Engine can also manage other types of business rules and therefore is useful apart from BPM.)

The choice of appropriate standard and tools depend on which use case is primary.

The confusion arises from the fact that the use cases, and associated standards such as BPEL and XPDL, are complementary, and partially overlapping. For a given situation, one or other standard and associated tools may be more appropriate, or both may coexist within an implementation.

Architectural Models

Modern applications have a generic conceptual structure, divided into tiers.

A “workflow” tool can be useful within the following contexts:

The protocols used to invoke process components vary depending on context.

Web Services has become a de facto standard for invoking services in an enterprise process context due to their interoperability and tool support. Web Services encompass standards for message exchange (SOAP), contract (WSDL), and binding (HTTP/S).

The temptation is to use Web Services for all service invocations, even within an application workflow context. Web Services are remote calls in nature, and involve marshalling data into XML; both of which add performance overhead.

Indeed, even within an enterprise process context, within an homogenous network environment, the benefits of using Web Services: standards based, common infrastructure; must be weighed against simplicity, performance, and guaranteed delivery of alternative messaging mechanisms, which are proprietary in nature.

For business-to-business (B2B) integration, Web Services usually makes perfect sense since an organisation usually has little control over the IT environment of a customer/partner organisation.

Page flows operate at the Application Programming Interface (API) level and are specific to the presentation technology and framework used, such as Java Server Faces vs. Struts.

The standardisation efforts have been focused on the enterprise process and application workflow contexts. It is within these two contexts that context boundaries can become confused: a primary application invoking external application services as part of its workflow, versus an enterprise hub which controls the process.

An architectural model sometimes raised in the context of BPM is where the “workflow is the application.”

Web Forms submit an XML message directly to the process engine to be processed. (The form controller code may be within the form as in AJAX (Asynchronous Javascript And XML) or handled by a Forms Presentation Server.)

This architectural model may work for simple human inputs. Larger applications have more complex screen navigation (page flow) and transaction management requirements that are best handled within the more typical application structures on the previous page.

Not every application problem is addressed by a workflow solution. However, workflow solutions, pragmatically applied, can create more adaptable applications.

Standards

The two main standards discussed below are BPEL and XPDL. The two standards are not necessarily competing but apply to different contexts.

BPEL

Business Process Execution Language (or BPEL, pronounced 'bipple', or 'bee-pell'), is a business process modelling language that is executable. It is serialized in XML as an orchestration language over a component set of web services.

BPEL provides a standard for orchestrating nodes in an EAI scenario, assuming that every node has a Web Service interface. Traditional EAI products made no such assumption and provided various adaptors for messaging, database, and packaged nodes. The downside was that the process language was tool-specific.

The problem with BPEL 1.1 within the BPM environment is that, as a standard, it was written with the orchestration of web services in mind. This means that there are some major limitations in the specification when it comes to handling human intensive interactions with the process (workflow tasks and sub-processes to name two). What this means is that the vendors who are relying only upon BPEL as a standard for their BPM tools are coding extensive (and proprietary) modifications to the standard to simply make their processes work. If those extensions are going to be supported in the future (and their potential impact upon interoperability and reusability) should be questions for all companies looking to go down that path. Their extensions certainly mean that you lock yourself in with them as a vendor.

As a language for Service Orchestration BPEL is good and thus is well suited for use within an Enterprise Service Bus (enterprise process context).

XPDL

XPDL is another standard developed by the Workflow Management Coalition (WfMC – http://www.wfmc.org/), which has been designed to support human intensive interactions, sub-processes, task management and all of the other things that the BPEL only vendors have to write extensions for. It was specifically designed to interchange Business Process definitions between different workflow products like modelling tools and workflow engines.

XPDL defines a XML schema for specifying the declarative part of workflow.

XPDL is designed to exchange the process design, both the graphics and the semantics of a workflow business process.

BPEL vs. XPDL (Executional processes versus a Workflow Management System (WFMS))

*** taken from Tom Baeyens (http://www.jboss.com/products/jbpm/stateofworkflow)

A recent trend in the BPM community is the convergence of specifications about executional business processes. The approach promoted by XLANG, WSFL and BPML converged into BPEL. BPEL is based on interactions (message exchanges). BPEL is defined in the context of a service-oriented architecture. One of the prerequisites is that the services to be addressed are described in a WSDL declaration. BPEL then specifies an XML grammar that can be seen as a programming language to combine control flow with calls to the services defined in WSDL.

I see three main differences between the approach taken in executional business processes and state based workflow management systems:

· State based versus message oriented: state based WFMSs are centred on the notion of state (or activity). The workflow engine maintains the state and calculates the transitions from one state to the next. On the other hand, executional business processes as BPEL are centred on the definition of reactions upon incoming message. A set of those reactions, along with some other bells and whistles, can be seen as a business process. That explains why BPEL is somewhat complementary to state based WFMSs. A BPEL onMessage event handler, which is a reaction upon an incoming message, could be executed e.g. on transitions between states.

· Process instance id versus message correlation: One of the complexities that are introduced with executional business processes is message correlation. Part of the process description must specify how the BPEL engine can detect the process instance identification from the incoming message. It has to be based on a data item in the message. On the other hand, state based WFMSs generate ids for each process instance that is created. The client can use this id in subsequent calls to the engine API.

· Central workflow engine API versus an abstract service endpoint: state based WFMSs have a central API, meaning that the client talks to one central API to manage executions of all process instances. In executional business processes, each process is exposed as a service. This means a different access point for every process definition.

Workflow is a subject from which you get easily distracted. The distraction occurs when workflow related concepts get mixed up with complementary technologies or concepts. To give a very concrete example: workflow is completely complementary to web-services. You could expose the interface to access a WFMS as a web-service, but it’s definitely a bad idea to presume that a WFMS *always* has to be accessed through a web-service interface. Some specifications make this presumption. Apart from web-services, other often occurring distractions include email, inter-business communication, web-applications & organisational structure.

The first standardisation effort in workflow was the Workflow Management Coalition (WfMC). The WfMC started in 1993. A very interesting publication of the WfMC is the reference model. It defines the interfaces between a workflow management system and other actors. Another piece of work is the XPDL specification. XPDL defines an XML schema for specifying the declarative part of a workflow. In my opinion, the reference model and XPDL are the best specifications.

BPEL is orientated around service orchestration, and expects every service to be exposed as a Web Service. Forms are supported; basically as XML inputs to a Web Service. These are more easily supported as trigger points to a process, but since there is no overarching state machine, defining conditional input, timed events, task allocation, etc. is not possible or must be embedded within a service (which begs the question of how to define these embedded interactions in a reconfigurable way).

XPDL is orientated around human workflow and includes features such as role-based task assignments, which BPEL 1.1 does not support. Service end points do not need to be a Web Service. XPDL or similar WFMS specification has a convenient mechanism for creating forms for tasks.

Process Context	Primary Standard
Enterprise Process (Enterprise Service Bus)	BPEL
Workflow	XPDL or similar WFMS language
Page flow	Currently proprietary format

Target Use Case	Primary Standard
Enterprise Application Integration (EAI)	BPEL
B2B Process Integration	BPEL
Service Orchestration	BPEL
Management of people-related tasks	XPDL or similar WFMS language

The standards are seen as complementary:

· XPDL as a standard used to represent the process within a visual design tool – a design-time language;

· BPEL as an output of the design tool – a run-time execution language.

Since there is no notation in BPEL to describe timers, roles, etc.

This view is consistent with the following explanation taken from http://www.wfmc.org/standards/xpdl.htm.

BPEL and XPDL are entirely different yet complimentary standards. BPEL is an "execution language" designed to provide a definition of web services orchestration, specifically the underlying sequence of interactions, the flow of data from point-to-point. For this reason, it is best suited for straight-through processing or data-flows vis-à-vis application integration.

The goal of XPDL is to store and exchange the process diagram, to allow one tool to model a process diagram, and another to read the diagram and edit, another to "run" the process model on an XPDL-compliant BPM engine, and so on. For this reason, XPDL is described not an executable programming language like BPEL, but specifically a process design format that literally represents the "drawing" of the process definition. To wit, it has ‘XY' or vector coordinates, including lines and points that define process flows. This allows an XPDL to store a one-to-one representation of a BPM process diagram. For this reason, XPDL is effectively the file format or "serialization" of BPM, as well as any non-BPM design method or process model which use in their underlying definition the XPDL meta-model (there are presently about 50 tools which use XPDL for storing process models.)

Business Process Modelling Language (BPML)

BPML is the workflow modelling language adopted by Microsoft, and .NET based products such as K2. It is superseded XLANG – an earlier workflow modelling language pioneered by Microsoft. It is from another standards body – “Business Process Management Initiative”, which is part of the Object Management Group (OMG).

BPML is a superset of BPEL; adding syntax for the workflow context.

BPML vs. XPDL

BPML focuses on issues important in defining web services. This is reflected in several ways:

· Activity types specifically for message interchange, event handling, compensation (in case of failure), and delay.

· Attributes to support instance correlation, extraction of parts of messages, locating service instances.

· Support for transactions, utilizing the block structure context, exception handling and compensation.

XPDL focuses on issues relevant to the distribution of work.

· Activity attribute specifies the resource(s) required to perform an activity. This is an expression, evaluated at execution time, which determines the resource required.

· Activity attribute specifies the application(s) required to implement an activity.

· These concepts together support the notion of a resource (e.g. participant), in conjunction with an application, performing the activity. The implementation of work list handlers to achieve this lies outside the domain of the process definitions.

Other Process Languages

Workflow specifications have been in a state of development. Some tools have implemented their own language in order to provide a pragmatic feature set. For example, JBoss BPM uses jPDL. jPDL is a process language with a clean interface to Java and very sophisticated task management capabilities. JBoss apparently has plans to support XPDL.

Approach

Regardless of the specific standard or implementation deemed appropriate, process definition starts with a description of the business process. An Activity Diagram, perhaps supplemented with a State Diagram, is a useful means of expressing the business process.

It is useful to have a conceptual understanding of the process before layering on the existing systems that participate in the physical view of that process.

The nature of the key business processes in terms of human involvement, existing systems, and events will provide input to tool selection. Other IT input then includes features, support, vendor “lock in”, price, etc.

Technologies

*** These are my high-level observations; not a detailed assessment.

All major vendors now have (mostly through acquisition) a Business Process Management (BPM) Product. BPM is typically at the high-end of their product range. The more progressive vendors are working out how BPM fits into a broader Service Orientated Architecture (SOA) suite. Alas, SOA marketing hype is creating more confusion than clarity.

Technology	Perceived Pros	Perceived Cons
JBoss BPM	Good integration to the presentation layer through JBoss Seam Framework and Java Server Faces (JSF). Good business rules integration. No upfront license costs.	More appropriate to the Workflow Use Case than the EAI Use Case. Uses its own workflow definition language jPDL.
Oracle BPEL	Oracle as the Number 3 Commercial Application Server Vendor, behind IBM WebSphere and BEA WebLogic, has been working hard to add support for the latest standards as a competitive tactic. There is a perception that the Oracle development environment is productive and that Oracle has learned from past mistakes in keeping its latest tools standards compliant.	The ability to build Workflow style applications needs more investigation. Oracle has in the past gone its own way leading to some dead-end technologies. Price.
TIBCO	Acquisition of the Staffware product provides a good Workflow product. BusinessWorks product has BPEL support and targeted more at EAI. Application Server agnostic.	Price.
BEA AquaLogic BPM	Sophisticated Business Modelling Tool (acquired from Feugo) targeted at business analysts and including simulation capabilities. Supports both BPEL (to import) and XPDL (preferred “from scratch” language).	Price.
IBM WebSphere BPM Suite	Comprehensive suite. A similar sophisticated modelling tool as BEA.	IBM can lag in support of the latest standards. A combination of products, which can make installation a pain. Price.
K2.NET	Suitable for Microsoft.NET environment. New version leverages Microsoft Windows Workflow Foundation. Business-friendly visual designer. Good reporting.	Not necessarily a con depending on the customer’s environment, but K2 is necessarily restricted to a Windows Server environment. Less suitable for EAI Use Cases; lacking integration patterns such as “Publish-Subscribe”.
Active Endpoints (Active BPEL Open Source Engine)	Open source – low upfront licence costs.
Spring Webflow (A Page Flow technology)	Works with various web application frameworks. Naturally integrated with the rest of the Spring Framework.
JBoss Seam (A Page Flow technology)	Great integration with JSF. Integrates with JBoss BPM and JBoss Rules to enable a consistent technology and representation for both page flow and workflow concerns.	Limited to Java Server Faces (JSF).
Others: Sun, Intalio, etc.

State of Rich Client Development

What is a “Rich Client”?

A “rich client” is an interactive application user interface, which employs dynamic controls that are updated immediately in response to user input. For example, the contents of a list may change in response to selection from another drop-down list, or validation messages are displayed in response to user input. A “rich client” is usually contrasted with a traditional HTML-based client, which can only update the state of the page in response to a form submission or following a hyperlink. The fact that we refer to screens as pages is because the browser was never designed as an application development environment. It was designed to navigate unstructured content.

Introduction

Rich clients are not new. The Client-Server platforms of the 1990's employed rich clients whereby the user interface ran as an application on the user's computer and communicated via a network with a central application or database. The Client-Server architecture suffered because at the time, the (rich) client applications were difficult to deploy and update. With the advent of the (World Wide) Web, application developers traded user interface functionality for ease of deployment.

Expectations do not stay satisfied for long. Users began to expect more functional and dynamic user interfaces, while IT managers expected the deployment capability of the web.

As a consequence, the Rich Client Platform (RCP) has been reborn to utilise the deployment benefits of the web.

The purpose of this paper is to discuss and evaluate the types of rich client platforms available today. As with the early stage of any new technology, there currently exists a range of options and architectures for implementing rich clients.

Rich Client Platform Types

Desktop Application

Desktop applications are the original rich clients and still the best in terms of functionality and responsiveness. They have improved in terms of look and feel, and graphics performance. They have also improved in terms of deployment options. While enterprise solutions such as Citrix have been around for some time, at a cost; the modern platforms – Java and .NET provide their own automatic deployment mechanisms – “Java Web Start” and “Click Once”. These enable applications to be automatically installed and updated each time the application is used from a web site using the ubiquitous HTTP protocol.

During the period of Client-Server technology, desktop applications were compiled for the desktop operating system. Modern platforms use a Virtual Machine and runtime environment, installed on the desktop machine, which provides application services.

A disadvantage of these runtime environments (e.g. Java Runtime Environment and .NET framework) is that they must first be installed on the desktop machine, and they are large downloads.

Some rich client platforms, such as the Eclipse RCP, employ another level of “container” for application services, which can support additional deployment scenarios, such as user-initiated update. However, the concept is the same, with the disadvantage of an additional download.

Desktop applications provide the state-of-the-art in what is possible with user interface design.

Desktop applications have been perceived as more difficult to build than HTML-based user interfaces. While this is still true when compared against traditional page-orientated web user interfaces; the difference has narrowed with AJAX user interfaces. The usability and productivity of tools to build desktop application user interfaces, using a “drag and drop” approach, has dramatically improved; e.g. NetBeans Matisse, and Microsoft Visual Studio.

Desktop applications have also suffered from a lack of a higher level application framework for integrating the user interface with server-side code; unlike web applications, which have enjoyed a multitude of frameworks. However, higher level frameworks for building desktop applications are now available; e.g. Eclipse RCP, Spring RCP, and JSR 296.

The most popular argument against desktop applications has been that they are more difficult to deploy and maintain. Customers are often not aware of deployment options such as “Click Once” for .NET, and “Web Start” for Java, which support automatic deployment and update over the Internet.

“Mini container” Rich Client Application

The title of this type of rich client platform is a made up one. It encompasses Flash and Microsoft's soon to be released Windows Presentation Foundation Express (WPFe). These are browser plug-ins that can display rich, interactive content including charts, animation effects, sound, and video. Flash technology has been around since 1996. According to one survey (http://www.adobe.com/products/player_census/flashplayer/), a Flash Player is installed on up to 98.3%[1] of Internet-enabled PCs in mature markets (defined as US, Canada, UK, France, Germany, and Japan for the purposes of the survey). WPFe hasn't been released out of beta but will be packaged with Windows Vista when ready.

I refer to them as “mini containers” because their download size is much smaller (1.1 MB for Flash Player 9) compared to the Java Runtime (7 – 13MB) or .NET Framework (22.4 MB).

The main advantage of this type of rich client platform is that because the application runs within a virtual machine embedded in the browser, the application is guaranteed to run, using the same code, across all browsers that support the “mini container”, which in the case of Flash is the majority of browsers in common use. In addition, since Flash was devised to display visually appealing dynamic content, the richness of the user interfaces is equivalent to that of desktop applications.

AJAX Application

AJAX stands for Asynchronous Javascript And XML, and is based on a feature of modern browsers which enables Javascript to make a web request and dynamically update the displayed page with the result, without forcing a complete page refresh. This feature enables an HTML page within a web browser to behave like a desktop application.

This feature has been employed for some time; since at least 2000 when I first remember exploiting the technique, which was based on the lessons of earlier work. The biggest problem with this approach was ensuring compatibility across browsers; each browser requires a slightly different implementation, which led to code repetition and increased maintenance.

The main advantage of this type of rich client application is that the only dependency on the user's machine is that a modern browser is installed. However, there are potential issues which require experienced developers to be involved in AJAX development. These issues include security, network bandwidth and utilisation, performance, and scalability. AJAX development is potentially more complex than development of desktop applications.

Over the last few years, AJAX frameworks have emerged which attempt to abstract the implementation details concerned with working across browsers, and provide standard controls such as data grids, trees, validating text boxes, etc. These frameworks have led to using AJAX for building complete user interfaces.

There is now a multitude of AJAX frameworks, which fall into these types.

Client-side Programming

Programming is done in Javascript or using a Builder Tool to build the user interface. Interaction with the server is achieved through consuming Web Services containing XML or more compact JSON (Javascript Object Notation) message. Examples include: Dojo, Prototype, and TIBCO General Interface.

Server-side Programming

There are two main sub-types of framework within this type.

1. Established web application frameworks have been enhanced to render AJAX-enabled controls. Examples include: Java Server Faces with Ajax4Jsf, ICE faces, or Apache MyFaces, Struts2, and ASP.NET. Builder Tools are typically used to provide a “drag and drop” environment for rapidly constructing user interfaces.
2. In the second sub-type, AJAX applications are developed using an Application Programming Interface (API) similar to that for building desktop applications. Examples include: Google Web Toolkit (GWT), and Echo2. In the case of Google Web Toolkit, all programming is done in Java, which is compiled into Javascript and certified to work across a range of browsers.

[1] Flex 2 – Adobe's rich client development platform requires the latest Flash Player Version 9 installed on around 55-65% of Internet-enabled PCs. However, a Flex 2 application can be configured to automatically upgrade the Flash Player to the required version.

Evaluation

Score: 1 (lowest) – 3 (highest)

Criteria	Desktop Application	“Mini Container”	AJAX
Runtime (Local Installation) dependency	1	2	3 The only requirement is a modern browser, but with Javascript enabled. Some AJAX frameworks support the ability for the application to fallback gracefully to traditional web behaviour, i.e. the display is updated only when the entire page is refreshed, when Javascript has been disabled.
Level of Richness/ Interactivity	2 The developer has complete control over the user interface.	3 Flash applications look polished by default.	2 AJAX applications depend on Dynamic HTML, which can create animated effects and use images to render buttons and backgrounds; however the developer will need to be proficient in CSS to achieve the same polish as Flash or desktop applications.
Developer Productivity	2 Builder Tools have improved substantially (e.g. Matisse), and frameworks are available (e.g. Eclipse RCP, Spring RCP, JSR 296). However, desktop applications, perhaps due to their flexibility, are still more complex.	3 Productive builder tools are used. Event handling is done using a scripting language.	2
Available Controls	3 A multitude of commercial and open source controls exist. Custom controls may be created by extending existing ones.	3 Controls are limited to those provided by the application framework, but are extensive.	2 Controls are mainly limited to common types, though more are expected to be added as the various frameworks mature, and the facility typically exists to create custom controls.
Support for occassionally connected clients	2 Desktop applications can be built to run standalone. A database system has been bundled with the Java 1.6 runtime environment (since Build 88). Commercial data synchronisation libraries exsit.	3 Abobe provide a data synchronisation library for its Flex 2 development platform. It is sold separately. I am not aware of the data synchronisation capabilities of WPFe.	1 Offline use is not supported by most AJAX frameworks. The Dojo framework has introduced a Javascript API to enable various storage providers to store data on the user's machine. Only one provider is currently included which uses Flash. The next version of Firefox 3 will have the three key components needed to support offline Web applications: DOM Storage; an offline execution model; and synchronization.
Use of proprietary technology (risk of lock-in or investment in dead-end technology)	3 Java desktop applications depend on the Java Runtime Environment (free and open source). Windows desktop applications depend on the .NET Framework (free but proprietary).	2 The Flex 2 Builder Tool is proprietary. Similarly, the WPFe tools and runtimes are proprietary.	2 Many of the popular AJAX frameworks are open source. Some are commercial products. The APIs are typically unique to the framework. The OpenAjax Alliance is defining a common API to enable customers to mix and match solutions from different providers.
Cross Browser Compatibility	N/A	3	2
Performance and Security	3	2	1
Proven Enterprise Deployment	3	1	1
Ease of Deployment	2	3	3

Possible Future Scenarios

1. Desktop applications make a come-back as new deployment options become better understood. For example, Sun or the open source community release a modular Java runtime environment, whereby a minimal runtime library can be downloaded. (The current Java download size is between 7 – 13 MB depending on the features selected. By comparison, the current Flash Player 9 download size is 1.1 MB. However, Apollo, Adobe's new virtual machine for running Flash and HTML-based applications outside the browser with off-line support is 6 MB.) The Java runtime environment web based installer is improved to enable Java Web Start applications to initiate an automatic version upgrade if required.
2. AJAX Frameworks consolidate and improve in terms of “out of the box” controls and polish.
3. Flash finally reaches mainstream based on the developer productivity benefits of Flex 2. Corporate application suites such as SAP and Oracle Fusion adopt Flash to display rich, interactive content (http://www.oracle.com/corporate/press/2006_oct/openworldsf06-06.html).

Conclusion

Rich Internet Applications will become more predominant driven by user expectations.

While desktop applications deserve more attention; in the short term, browser-based applications are more likely to be commissioned. In particular, the e-GIF standard in New Zealand (Government Interoperability Framework http://www.e.govt.nz/standards/e-gif) will direct Government applications to be HTML-based. This restrains development as dual-mode user interfaces: rich (requiring Javascript or Flash to be enabled) and standard are cost prohibitive.

Business applications are likely to evolve from the current HTML-based applications to add rich features using Javascript (AJAX) or Flash. Entire applications are unlikely to be developed using Flash; instead specific features, such as dynamic charting may be Flash based, while other features such as mapping (using a Google Maps mash-up) may be AJAX based. AJAX and Flash is likely to coexist. This architecture is also consistent with Adobe’s recommendations.

In the Microsoft world, the choices are more straightforward: ASP.NET utilising AJAX features initially and perhaps WPFe.

In Java, there are many choices. Java Server Faces (JSF) is the Java Enterprise standard for HTML-based applications. Using AJAX frameworks that integrate with JSF is a safe choice. However, JSF is hard to love from a developer’s perspective (http://icoloma.blogspot.com/2006/10/myfaces-emperor-has-no-clothes.html http://timshadel.com/2006/01/19/jsf-the-7-layer-burrito-i-wont-eat-again/). It adds complexity to do some things that should be simple, such as page navigation. These complexities can be addressed with a framework such as JBoss Seam (http://labs.jboss.com/portal/jbossseam/).

In fact, the JBoss application stack appears compelling, largely due to the Seam framework enabling a clean integration between the presentation (JSF), services (Workflow using JBoss BPM and Rules using JBoss Rules), and data access (EJB 3 or Hibernate) layers, to provide a complete enterprise application framework.

If your application needs do not require a rich user interface, then the following web application frameworks have proven robust:

1. Spring MVC, part of the Spring Framework (http://www.springframework.org/).
2. ASP.NET (http://www.asp.net/).

What would I use? It is frustrating that at this time, this is a difficult question to answer.

If the application is large and the need for immediate feedback in a screen is limited to a few controls, I would probably play it safe and stick with a framework such as Spring MVC, and look to develop those controls using Flex or an AJAX toolkit, such as DWR (Direct Web Remoting http://getahead.org/dwr). I would also feel comfortable using Struts2 (ex WebWork).

In addition, since many of my current customers are in Government, accessibility and interoperability guidelines mean that public facing applications must support a lowest common denominator environment; e.g. applications must be able to operate without Javascript enabled and across a wide range of browsers. This leads to a traditional HTML-based application.

If the application required rich features combined with complex server-side logic, such as multi-page forms, long-running transactions, or volatile business rules, then I would consider using JBoss Seam with JSF.

If the application was small then I would consider using Adobe Flex with the Flex Builder. I would use Flex 2 over WPFe at this time given the maturity of Flash.

These conclusions may change as the technologies and customer needs evolve.

Technology Watch List

1. Adobe Flex 2 (http://www.adobe.com/products/flex/).
2. JBoss Application Stack, with JBoss Seam in particular (http://labs.jboss.com/portal/jbossseam/).
3. JBoss Ajax4jsf to add AJAX capabilities to the JBoss Application Stack (http://labs.jboss.com/portal/jbossajax4jsf/).
4. Google Web Toolkit (http://code.google.com/webtoolkit/).
5. Instantiations GWT Designer as a Builder Tool for the Google Web Toolkit (http://www.instantiations.com/gwtdesigner/).
6. Microsoft Expression Blend Design Tool for building WPFe applications (http://www.microsoft.com/Expression/products/overview.aspx?key=blend).

Why this blog?

As part of my job, I write articles about various technologies and trends for the benefit of customers and staff.

The articles don't necessarily reflect the views of my employer, but have been based on projects across a wide range of customers and industries.

I consider myself a generalist in the field of delivering technology based solutions to enterprise-sized customers. I find the best way to understand new technology is to write some code. My interest is in applying (understanding, designing, selling, managing) technology for business change: to improve customer service or to quote someone, "make the simple things easy and the complex things possible."

These articles help me collect my thoughts on various topics in order to make sense of the bigger picture.