About this book

This user guide provides information on using and developing applications with Aria. The guide is organized into an number of sections.

• Section I Begins with an introduction to Aria, its history and its position on the technology landscape.
• Section II Describes the Aria Integrated Development Environment (IDE) and the basic features that are commonly included in an application are explained.
• Section III Covers more advanced features and the features that are required to build full-featured client-server applications.
• Section IV Illustrates many features by way of case studies.

The guide then concludes with a selection of reference materials.

Formaria also provides step-by-step tutorials, courseware and on-line reference manuals so the focus of this manual is on explaining the concepts of developing applications with Aria. The Formaria web site also features a developer zone where you can find working applications and numerous technical articles.

User Guide Conventions

The documentation for Aria uses the typefaces and symbols described in the table below to indicate special text.

Typeface	Meaning
Monospace type	Monospaced type represents text as it appears on screen or in Java code. It also represents anything you must type.
[]	Square brackets in text or syntax listings enclose optional items. Do not type the brackets
<>	Angle brackets in text or syntax listings indicate a variable string; type in a string appropriate for you code. Do not type the angle brackets. Angle brackets are also used for HTML tags.
...	An ellipsis in syntax listing indicate code that is missing from the example.
Italics	Italicized words represent Java identifiers, such as names of variables, classes, interfaces, components, properties, methods, and events. Italics are also used for new terms being defined
Keycaps	This typeface indicates a key on your keyboard for example, “press ESC to exit”.

Contacting Formaria developer support

Formaria offers a variety of support options. These include free services on the Internet, where you can search our information base and connect with other users of Formaria products. in addition you can choose from several categories of telephone support, ranging from installation support to fee-based consultant-level support and detailed assistance.

For more information about Formaria’s developer support services, see our website at http://www.formaria.org.

When contacting support, please be prepared to give complete information about your environment, the version of the product you are using, and a detailed description of the problem.

Introduction

This is a draft update of the manual. The Aria project contains some recent changes that are not entirely reflected in this book. In particular classs names no longer start with an X, there is no `optional' package (just renamed) and the build process for the framework and the IDE plugins has changed and the description is yet to be updated in this book.

Aria is a Java and XML framework for creating applications with rich user interfaces.

Aria includes a plugin for the netBeans integrated development environment making the development and testing process as easy as possible without locking you into a proprietary solution. Aria also has a rich set of libraries, tools and wizards for rapid application development.

What is Aria?

First and foremost Aria is a framework for building Java and XML based applications. The aims of Aria are to:

• Reduce the amount of code needed to build an application
• Provide a clean application architecture and infrastructure
• Simplify building and maintaining applications
• Allow easy extension and customization
• Enable lightweight and performant applications

The core of Aria is a small Java library that allows 'pages' of an application to be constructed from an XML declaration or from Java code. Aria offers many add-ons and extensions including a graphical editor/IDE.

Aria can be used for simple single page applications and forms or for complex business applications comprising many page and resources.

What can be built with Aria?

Aria can be used to build a wide variety of applications just a few of which are listed below:

• Simple form based applications
• Management consoles
• Catalogues, Configurators, Browsers
• Selection tools
• Guides/Brochures
• Retail and Point-of-Sale applications
• Kiosk applications
• Mobile applications for field workers and road warriors
• Surveys and market research applications
• Database applications
• e-learning applications
• Informational and promotional applications

Aria is a general purpose tool so it can be used to build just about anything you can imagine building with Java and XML, but it offers the greatest advantage when building client side applications.

Aria also includes many sector specific features and add-ons. See the Xoetrope website for more information on add-ons and case studies highlighting how Aria's has been used to build specific solutions.

What does Aria do?

In a nutshell Aria can be used to build feature rich, smart-client applications. Smart client applications are typified by their ability to make use of client-side computing power. Notably this means that such applications exhibit;

• A feature rich user interface
• A fast and responsive user interface
• Ability to work on-line or standalone
• A simplified application construction
• Ease of updated and processing of dynamic content
• Built-in data management
• Sophisticated functionality
• Optimized bandwidth usage
• Low maintenance and administration characteristics

All of these features can be found in Aria built applications. Furthermore, being Java and XML based, Aria applications are portable so that they can run on a wide variety of devices and platforms.

As a development platform Aria leverages the usual drag and drop techniques to make building applications quick and easy. Aria includes numerous widgets, library functions and wizards to make many common tasks simple.

Simplicity really is the key to Aria, so even if the feature or behavior you desire isn't predefined it usually isn't difficult to implement. As an open system Aria even allows such additions to be made in a reusable way so that you may only need to define the addition once. Even if you need to go beyond Aria's capabilities you can work directly with Java and XML or with third party tools. So, ultimately Aria make the developer's life easier.

How does Aria work?

Aria takes advantage of local computing resources, so instead of going back and forth to a server a Aria application can store and process information locally. As a result you don't see the delays that are typical of some web-based applications. Using the local computing resources means that you can make an application more responsive, offer more and better user interaction and build smarter applications, so-called Rich-Client or Rich Internet Applications (RIA).

Making use of local computing resources also helps simplify some of the tasks involved in building modern software applications. If you don't have to go back and forth to a server for information you don't need to do so much to maintain state information. Furthermore if you can eliminate input errors at source then your business processing should be less complicated.

In addition to the implicit benefits of a rich-client framework Aria also applies some well known architectural techniques to further simplify the process of building applications. The most important of these concepts is the Model-View-Controller (MVC) pattern. With this pattern the key components of an application are separated from one another to simplify development. In Aria the MVC architecture is promoted by the natural separation of the various components in framework and by the coding styles and techniques used for each component.

The Aria MVC components equate to

• View: Pages defined in either XML or Java.
• Model: The data, declaratively bound to the pages or view.
• Controller: The application logic specified in Java and declaratively bound to the other components.

Aria also supports declarative user interface specification and declarative data binding whereby pages, data bindings and event bindings can be specified in XML independently of one another. The late coupling this provides has a number of benefits. Pages can be delivered or updated independently of one another much like HTML pages. This sort of independence of content was one of the major benefits of thin-client and web applications yet Aria manages to deliver similar behavior and benefits in a rich-client framework. Aria however achieves this while leveraging the Java platform, in the process delivering efficient, modular and reusable components.

Much of Aria's benefits stem from this loose coupling of components. Since the View is loosely couple to the data model a new look and feel can be placed on an application with minimal implications for the application behavior or coding. Similarly the application logic can be coded with minimal reference to the user interface or how data is bound and update to that user interface. Imagine being able to write the code for even a simple equation without having to know when or how the input fields are filled out or how to then display the results of your calculation.

The separation of roles pays dividends in a number of ways. People of differing skills can collaborate on a project with perhaps one concentrating on the user interface and visual side while another may be responsible for business logic or data processing. Whether this is actually a realizable business benefit is a moot point, but in the long-run the benefits are very real.

In a maintenance mode it may be many months since a particular feature or aspect of an application has been developed. Being able to `fix' a bug in say the business logic in such a feature is considerably easier when you don't risk breaking a user-interface feature or the data setup or vice versa. Furthermore without mixing user-interface code and business logic the role and intent of each piece of code is more apparent and this make understanding each part of the application a little less involved.

Aria is in some senses is a fairly typical development environment or framework for building Java applications, a plug-in for the NetBeans IDE is even a key feature. Aria however aims to make the process of building and maintaining applications as simple as possible.

Using the techniques described above Aria eliminates much of the normal `plumbing' code and allows you to get on with building real value into your application. In saving large amounts of coding the burden of developing and maintaining applications is also greatly lightened.

Licensing

Aria is available under the open source MPL and GPL/LGPL license which allows developers to download and use the software or to bundle it with commercial applications.

Any enquiries about licensing can be addressed to support@formaria.org.

Why Aria

There is no doubt that modern software is complex, and this complexity it often the bane of quality, performance and usability. Aria started out as a way of making life easier for the developer. The framework initially set out to eliminate some of the most basic and tedious coding tasks rather than as a complete replacement for existing practices. The stratgey of augmention rather than replacement has been followed throughout the frameworks's development and this leaves the developer free to use the best tools for a particular job, using all of Aria or just those parts that suit.

Over time Aria has developed to include a range of advanced features and tools that ease the task of building modern applications, but Aria's central theme remains the task of making it easier to build advanced, feature rich applications.

Background

Aria is a Java-based system that sets out to solve many of the problems encountered when building Rich Internet Applications (RIA).

Users are demanding more features, more performance, better integration and generally greater usability from their applications. A competitive market and demanding users means that modern applications are becoming more and more complex, often to the point where development is at the limit of the available resources and maintenance is highly expensive. For the many organizations this complexity may translate into less that ideal behavior or reduced functionality within the application.

While Aria is based upon Java, Java in its basic form can be misused, and to some extent Java suffers from some shortcomings from the application developer's perspective in that there is no out-of-the-box support is included for high-level abstractions such as the MVC architecture, and there is little high-level support for communication and data-access, and in some cases excessive plumbing is often required to perform simple tasks.

Aria aims to eliminate much of the plumbing involved in building RIAs, so that the developer can concentrate on adding value to the application.

Many of today's client applications, be they built on Java or not, suffer from code bloat and poor maintainability. Poor maintainability often derives from the use of IDEs and the throwaway nature of the code they generate. Unaddressed, this lack of emphasis on good design and quality leads to poor performance. For many, this poorly constructed application type is typified by the monolithic fat-client application, with all its deployment and maintenance issues.

One common solution to the problems of fat clients is to employ a thin-client architecture, moving processing to the server side and removing client administration woes, yet this solution is not without its own perils. Shifting the problem of poor design to the server won't win many awards and introduces many of its own problems, like security and session handling, not to mention performance.

Hybrid application types like Ajax share most of this thin-client legacy but added apparent interactivity, however, this comes add the price of even greater complexity and all without the architectural merits of either the fat or thin client application. Ajax applications also suffer from a lack of tooling, whereas a typical Java developer will have an abundance of superb tools.

Despite the poor reputation gained by some client applications, there has been a resurgence of interest in smart client applications. Most client devices, even handheld devices, now have sufficient processing capability to perform useful work and this is wasted in a thin-client environment. Many of the fat-client problems have been solved and the thin-client solution is not the panacea that many had desired.

The Aria library is an open-source framework designed to solve some of the problems involved in building modern smart client applications.

Why do we build applications at all?

It may seem obvious to say that we build application to meet business needs, yet it is worth reflecting on the bigger picture. What do we hope to accomplish with our applications?

Typical requirements include getting the work done in an efficient and effective manner and having a reliable and maintainable system. All quite straightforward, but what about keeping the customer happy? Quite often the job is not just about getting the immediate business done but also about keeping the customers happy.

Many of today's applications fall short of providing an all round satisfying user experience. Frequently the user simply wants to accomplish the task at hand with the least amount of pain. At other times the user wants a richer, more informative experience, one that adds value.

Aria can help you provide fast and effective client solutions.

The Form Metaphor

According to 2001 analyst estimates American businesses alone spend upward of $15 billion transferring data from paper-based forms such as loan applications and purchase orders to their computer systems. Billions more is invested every year in web based forms and other electronic forms. Not surprising when you consider the ubiquity of the humble form. Almost every business process involves form processing of one sort or another. In a broader view forms are an essential part of the data capture process for many businesses.

Electronic data capture and form processing offers many advantages over paper alternatives and act as the basis for a wide range of business applications. In many cases it may not even be possible to achieve comparable results with a paper based approach. Electronic forms can be of great value to both the end user (ease of use and error checking) and for backend processing (speed, quality and security).

Today a wide range of technologies are available for electronic forms processing. Many of the newer technologies are enabling completely new areas of automation and better, more functional applications. Couple this with other related technologies like mobile computing and wireless communication and you have many exciting new opportunities for improving workflow and communications.

From a business perspective automated form processing can bring many returns above and beyond the direct savings. The improved data can lead to better analysis of the customer relationship. Closing the enquiry-sales-fulfilment loop to manual data entry can even reduce leakage from the sales cycle. Where field workers or representatives are involved, faster more efficient technology will empower the employee.

In an application context the notion of a form can be quite vague but for the purposes of this guide we will assume that a form is a fairly discrete component that helps capture a subset of data. How that form is presented to the user can vary greatly within the definition of the user interface but from the point of view of the application logic the form's role is fairly well defined and helps for a logical subdivision of an application.

Beyond Forms

HTML forms have been the mainstay of web applications for some time. Although forms can be considered a workhorse of data capture, their use as the de facto user interface is not particularly well suited to the demands of modern business processes or for more complex application design. It is common for applications to comprise whole sets of forms and much of their value comes from relating the information on one form to another and to business intelligence.

It is easy to see that the smarter an application appears and the more responsive it is to the user, the richer the experience. Many of the web technologies in use today go to great lengths to provide such responsiveness and such intelligence, yet in many ways they face an uphill struggle. The infrastructure required to deploy some of these frameworks can be significant and rapidly pushes up the total cost of ownership despite what may be the obvious technical merits of an individual technology.

HTML was designed primarily for the display and linking of static text and static content. Extensions, plug-ins and many server side technologies have added to the power and capability of the basic HTML technology. The so called thin client that these technologies popularized has gained enormous popularity over the last few years. Despite the ubiquity and popularity of the thin client there are many areas where these web technologies have been less successful.

HTML's limits

An HTML application or form normally requires a request to the web server to provide updated content. Plug-ins or scripting may be used in some situations to avoid the round trip to the server and provide some element of local interactivity but often at the cost of complexity.

For anything other than simple applications the mix of HTML, JavaScript and server side technologies can rapidly lead to a complex technology solution. In many ways the solution is often more complex that the original problem. The more complex the applications become the greater the strain for these solutions to be effective.

Even without the implementation and delivery issues, HTML based applications suffer from the inherent delays associated with having to make frequent requests to the server. A simple round trip leads to noticeable delays in responding to user interaction and hence there is a limit to what is effective in terms of user interactivity with such applications.

Scripting

One of the defining characteristics of many web frameworks is the use of client-side scripting technologies. While scripting may be acceptable for small scale use it does not work well for large scale use. Scripting lacks many of the object-oriented features that programmers expect of a modern platform. Couple this to the common problem of separating roles with a environment that normally sees scripts embedded in user interface declarations and you can end up with a complex mess.

Underlying HTML's use is of course the browser, with all its security restrictions and compatibility problems. Even within an individual browser the lifecycle of a page can prove troublesome, making it difficult to maintain state. HTML is just not a natural fit for the needs of many modern applications.

Application delivery in a connected world

Today, a new range of connected workers has emerged, the road warrior, the business traveller, the salesman, the field worker, the PDA/Smart device owner. This type of user presents many new challenges. Typical of these demands is the occasionally connected nature of their usage. It's not much good to have smart devices if it is assumed that the application software needs constant connectivity, or if the applications cannot cope with loss of connectivity mid session.

Rich Client to the Rescue

Desktop computers and even the majority of mobile devices have significant computing power and therefore it is well within their capacity to handle much of what is delegated to the web server by thin client applications. One of the cornerstones of performance is locality of computing. Holding true to this maxim, locality of computing for a form application means that such things as data validation, prompting, user interaction can be handled locally. Doing things locally means not having to wait for a round trip to the server to complete. This alone can lead to faster, more interactive applications and interacting with data locally can also facilitate disconnected and mobile applications. Add to the local interactivity the rich user interfaces that can be built for today's rich client applications and you can get some very attractive applications.

So Why Aria?

Aria is a rich client application development platform designed to improve the way in which Forms and internet applications can be built. Bringing together two powerful technologies, Java and XML, Aria offers many advantages in terms of ease of development, performance and portability. These advantages lead directly to reduced development and maintenance costs. The rapid development process that Aria enables also means that you may have more time to devote to improving content and creativity.

The open source Aria framework addresses many of the problems discussed above and then some more. Aria adds many additional widgets for building applications and business sector specific features and wizards, not found in the basic open source platform. Aria also provides client-server support so that applications can more easily work within a corporate environment and communicate with back-end services.

Aria comes with a feature packed editor and is built in an open way, supporting open standards. Vendor lock-in is avoided and the editor can be used in conjunction with other tools. So even if your authors and developers don't want to use low level technologies like XML they can build applications with the familiar drag and drop metaphors.

The Development challenge

For many organizations the move to thin clients was driven by administrative issues as much as implementation ones. The thin client was seen as a way of reducing administrative and helpdesk requirements as the client application had zero footprint. Furthermore the assumed ease of updating content was considered a major benefit in itself.

The penalty for this approach was that more responsibility was placed on the server side. All the users, all the user information and preferences had to be managed by the server. All the processing was shifted to the server as well. While architecturally this structure may have seemed simpler it often involved several tiers and a large array of systems.

The return of the rich client will not do away with many of the demands placed on today's servers but it will certainly reduce the load and in many ways simplify the applications. With each client managing its own state the server can be focused on providing the centralized enterprise level facilities to which it is best suited.

A rich client framework like Aria implemented in a single language is considerably simpler than the highly layered approaches common in today's thin client systems. The problems that dogged rich clients of the past are but a memory. Zero footprint and incremental updates are a given. Security and a richer user experience are bonus.

Individual features of Aria are worth using on their own not to mention using them in concert with other Aria features. Take for example Aria's method of constructing user-interface components via factories. This feature alone saves large amounts of code over what would be generated by a typical IDE. Aria is a modular system so you can employ just one feature like this on its own, mixing and matching to your needs. Aria, can therefore be integrated into new, old or legacy applications without difficulty. For legacy applications the Aria framework can provide a convenient way of adding new and modern features to what may otherwise be tired looking applications.

Above all Aria is designed by programmers for programmers.

Related Technologies

Aria is built upon an open architecture and hence it can support a wide variety of technologies. Equally Aria can be used in an ad hoc manner whereby parts of the package can be used and other parts replaced or supplemented by other technologies. Aria was designed to support good programming practices and the use of best of breed tools so in many ways the technologies listed in this chapter need not be seen as competing technologies and can be used comfortably alongside Aria.

Aria versus HTML

HTML is well known and can be used for a wide variety of presentations and even for simple form applications. However HTML is not well suited to anything other than trivial applications. The mix of HTML with the scripts typically needed for interactive web pages can be a nightmare to develop and maintain. The scripting code tends to get heavily embedded in the HTML and it is therefore difficult to decipher and reuse.

Numerous attempts have been made to address the needs of web applications but many of these attempts require large plug-ins or are restricted to a Windows platform. We believe that Aria strikes a good balance, requiring no plug-ins, a small download requirement, pages that can be downloaded individually or en-masse all while still managing to have powerful programming capabilities.

The XML used by Aria is easy to read and understand. Separation of the scripting means that the XML is clean and compact; ideal for offloading to a graphic designer if so desired. The Java code used in place of the XML can run in the browser's native environment and is pure code, again no mixing of content so from the programmer's perspective this too is desirable.

Aria versus AJAX

AJAX isn't a new kid on the block, having been around in many guises for several years. AJAX is essentially a technique for updating a web page without having to request a page refresh. AJAX can update a fragment of the page and the end user has the impression of a more responsive environment as only some of the page updates. Indeed AJAX may be a little more efficient than vanilla HTML as the fragments of HTML/XML it pulls down during updates will conserve some bandwidth.

AJAX can enable some client side processing of data but it is at heart still a scripting technology, still burdened with all the drawbacks of scripting and of being browser based.

Aria versus Java

So why not program in Java? Aria's use of XML makes it compact and simplifies the process of creating forms and more generally simplifies the creation of a UI. The separation of concerns means that the core business logic can be separated from the UI with the consequence that the code is easier to develop and maintain. Not only that, but the code is also more likely to be reusable. In comparison to a Java solution developed with a typical integrate development environment we normally see a reduction of 50-70% in the size of the codebase.

Despite the benefits that Aria can bring we do not mean to suggest it can do everything. Java is a very powerful programming platform and Aria has been designed to work with Java and therefore the full power of Java is available to a Aria application.

Careful coding means that Aria can run with the browser's built in Java support (JDK 1.1.4 of Internet Explorer) and on a wide range of mobile devices. The result is that you aren't really faced with the choice of Java or Aria; rather you have the option of using the best features of both systems to give a powerful small footprint system.

Sun's Swing and NetBeans teams continue to make great strides in improving the Java desktop experience, however, most of the new technologies they introduce require a recent JDK and this may not be available to everyone. Most of Aria's technology is available on a wide range of JVMs.

Despite the overlap between Aria and some of the newer Swing features we plan to support emerging technologies as they mature and become available, particularly where they are standardized. Aria 3.0 introduces a new application architecture to make it easier to customize the basic application startup and behavior, and in this respect additional support for Swing has been added by way of a new startup object that can essentially integrate a Aria application as a component within a run-o-the-mill Swing application. Aria 3.0 also extends the Swing widget support, making use of third party Swing components very simple.

So what does all this mean? Well Aria and Aria play very well with Swing and standard Java desktop technologies. For the most part you can view Aria as a code saving technology for Swing, and after that you can use the normal Swing coding conventions.

Aria versus Servlet and Server Side Technologies

A number of server side technologies have been used to assist in the development of web applications. The Apache Foundation has produced several of these libraries, notably the Struts library. Sun, Microsoft, IBM, Oracle and others have added to the range of server side technologies available to the developer. The various technologies that these tools offer almost all produce HTML or XML that is rendered on the client. The server side tools add many facilities for validation of data and control of the client integration with the server but on the whole they fall short of offering the type of rich client that can be built with Aria and the client side technologies outlined above.

Of course most modern applications rely on a server side process to implement key business functions. Aria is no different and in this sense it is complementary to server side technologies. However Aria relieves the server of the challenges involved in much client state information.

Aria can integrate with business components on the backend via a variety of protocols and processes, be that simple HTML forms, J2EE, Soap or .Net. Aria's service model neatly encapsulates these services so that the much of the detail can be hidden from the application programmer.

Not only can you choose Aria and/or Java but using XML you can easily move from AWT to Swing, without recoding, so for a Windows user this means it is possible to run with Internet Explorer without need for additional downloads or plug-ins.

Support for other widget sets (e.g. LCDUI/Blackberry) is being developed from prototype).

Aria versus .NET

Microsoft's .Net platform has been gaining widespread coverage and Microsoft has made some forays into the forms market. Aria can be run on this platform via the J# language (a clone of Java) if required. On some mobile platforms this may be desirable where a JVM is not available or is a cost impediment.

However Java is by far the more mature platform and the available resources are far more extensive. In using .Net there is also the risk of getting locked into a Microsoft environment and the consequent costs. At the core, Aria being an open source platform gives you plenty of options.

Aria versus XUL , *XForms, XAML et al

Mozilla, Microsoft and others have produced a variety of XML formats for user interface description. These formats share many of the same objectives as Aria and unsurprisingly they use many similar techniques to construct applications. One of the advantages of XML in this context is that the formats are relatively open and so it is possible to render these documents with the Aria add-on libraries published by Formaria.

Aria differs from these libraries in a number of key ways. Firstly XUL and its variants rely heavily on client side scripting making them more difficult to program and maintain than the pure Java used in Aria. Many of the XUL variants are rendered with the Java Swing library making them unsuitable for resource challenged situations such as exist on mobile devices, Aria can be rendered with the AWT and hence memory and bandwidth are conserved. And of course XUL can't be compiled so it always pays the cost for parsing

Microsoft's XAML format deserves separate mention even though it is in many ways similar to XUL. XAML of course is not yet widely available. The licensing model offered by Microsoft may make use of XAML prohibitively expensive and the availability of XAML clients may be limited to the very latest Windows desktops.

Of course given Microsoft's strength in the market place the impact of Longhorn and XAML will be significant. The XAML architecture mimics that of Aria in many ways and provides many of the same features and facilities so we take this as an endorsement of the Aria architecture. In many ways Aria does for Java what XAML does for Windows.

The World Wide Web consortium is promoting XForms as part of the XHTML standard and again this offers a variation on the XUL theme. XForms embodies a rich data model and supports lifecycle semantics for a rich web client. Like XUL, XForms relies heavily on scripting, although to a much lesser degree than HTML forms. Again the add-on Aria libraries can render and interoperate with XForms. Aria differs in that its data model and update semantics are more cleanly separated in the industry standard MVC architecture making for a clean maintenance structure and clear programming structures.

A prototype filter is under development that allows Aria to read formats such as XForms, Infopath and XAML.

Aria versus Ajax

Ajax is something of a juggernaut powered by the hype surrounding Tim O'Reilly's Web 2.0 notion, however Ajax has been around quite some time and even featured in a precursor to Aria and Aria. Without doubt, Ajax is an improvement on vanilla HTML and even DHTML, but as has been mentioned above this comes at a price. Ajax applications are often quite complex, having a mix of client and server side technologies and a mix of programming metaphors and language. While this might be highly important to developers, end users probably couldn't care less about this complexity, so long as they can get the job done. Therefore Ajax has alot of merit and may well be the best choice for some applications. Conversely as applications grow and the shortcomings of the Ajax platform begin to exhibit themselves then a Aria or Aria based application begins to become more attractive.

Quite often the power user will demand better performance or better desktop integration than can be delivered by Ajax and here Aria can help. Therefore, if the system is not too complex and there is only occassional or light use of an application then Ajax could be a good choice. Where performance, or integration, or flexibility, or complexity are bigger issues then Aria may be the better option.

What may surprise some, who wrote of Java as slow and clunky, is that a Java application like Aria can be visually attractive, with lots of rich user interface features and great performance. Where that visual impact is important Aria is also the better option.

Other issues

The technology used in Aria is only one part of the overall application development story. There are many factors that affect how a project is implemented and managed. The following sections highlight some of these important factors to consider when embarking on a development project of any significance.

Legacy application support

Not everyone has the luxury of starting with a clean slate, and importantly Aria does not necessitate such an approach. The open architecture employed by Aria makes it easy to use Aria when and where possible. This may simply be the use of Aria to cleanup some code or it may be more extensive. Aria can be added incrementally to a project.

Legacy applications frequently suffer from maintenance issues such as spaghetti like code and the mixing of concerns so that it is often difficult to identify key business logic. Aria can greatly simplify this code by allowing much of the plumbing to be removed or hidden. Not only does this save code and reduce the complexity but it also make the business logic more apparent.

But why fix a working system? It's quite simple really; it's easier to maintain a small code base than a large one, and it's easier again to maintain a clean code base than a convoluted one. Using Aria as part of the cleanup means that the real value in an existing application can be preserved and prepared for tomorrow's challenges rather than facing a rebuild.

Aria's support for new technologies like POJOs, data binding and modern user interface components also mean that Aria can be a good choice for extending, reviving or refreshing existing applications.

Simple single language support

Many of today's applications and systems are composed of a variety of subsystems, often in different languages and invariably requiring multiple developers with different skill sets. In contrast Aria has a single language implementation. Java is used throughout and can be supplemented with simple XML (and this XML can be hidden from sight by use of the IDE).

Separation of roles

Aria promotes a clean architecture by separating development roles and concerns. As has already been remarked Aria makes business logic stand out by removing plumbing code. Aria goes further by separating the applications data, services and user interface into distinct components. Not only does this facilitate maintenance but it also helps promote good development practices.

Occasionally connected

Modern applications have to cope with a wide variety of connected devices. Despite the ubiquity of internet access it cannot be assumed that there is always a connection available. Even if there is a connection available quality of service considerations, or security concerns may mean that an application must cope gracefully with intermittent connectivity.

Aria not only supports this capability but provides sophisticated mechanisms for handling remote communications, routing and fault tolerance. Added to this is Aria's ability to support store and forward mechanisms so that once connectivity becomes available data can be sent to the server or updates retrieved.

Branding

Many companies sell through channels and these channels require branding of the application to suit the channel. Aria stylesheets facilitate this rebranding without change to the code.

Within Aria you can easily replace colors, fonts, text and other resources. This together with the separation of concerns enforced by the MVC architecture means that you can efficiently build an application to support multiple brands or sales channels. Furthermore the open architecture means that it is possible to deliver modular solutions whereby resellers and related businesses can integrate content in a coherent manner.

Performance and server load

Because Aria promotes the idea of a rich client and of performing more processing on the client side there is a consequent reduction in the load on the server. This locality of computing also leads to direct performance gains from a user perspective. Local calculations may not require a round trip to the server for data retrieval and once retrieved the data can be accessed efficiently. Moving processing to the client also removes several layers of processing (security, load balancing, logging etc...) from the server so not only can the processing/calculation be performed efficiently on the local machine but the server can also act in a more efficient manner by serving up coarse grained objects (more content and less overhead as requests are amalgamated).