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