4 Related Technologies
Carousel is built upon an open architecture and hence it can support a wide variety of technologies. Equally Carousel 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. Carousel 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 Carousel.
Carousel 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 Carousel 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 Carousel 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.
Carousel 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.
Carousel versus Java
So why not program in Java? Carousel'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 Carousel can bring we do not mean to suggest it can do everything. Java is a very powerful programming platform and Carousel has been designed to work with Java and therefore the full power of Java is available to a Carousel application.
Careful coding means that Carousel 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 Carousel; rather you have the option of using the best features of both systems to give a powerful small footprint system.
Carousel 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 Carousel and the client side technologies outlined above.
Of course most modern applications rely on a server side process to implement key business functions. Carousel is no different and in this sense it is complementary to server side technologies. However Carousel relieves the server of the challenges involved in much client state information.
Carousel can integrate with business components on the backend via a variety of protocols and processes, be that simple HTML forms, J2EE, Soap or .Net. Carousel'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 Carousel 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).
Carousel versus .NET
Microsoft's .Net platform has been gaining widespread coverage and Microsoft has made some forays into the forms market. Carousel 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, Carousel being an open source platform gives you plenty of options.
Carousel 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 Carousel 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 Carousel add-on libraries published by Xoetrope.
Carousel 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 Carousel. 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, Carousel 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 available and its release is someway off (expected 2005). 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 Carousel in many ways and provides many of the same features and facilities so we take this as an endorsement of the Carousel architecture. In many ways Carousel 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 Carousel libraries can render and interoperate with XForms. Carousel 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 Carousel to read formats such as XForms, Infopath and XAML.
Other issues
The technology used in Carousel 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 Carousel does not necessitate such an approach. The open architecture employed by Carousel makes it easy to use Carousel when and where possible. This may simply be the use of Carousel to cleanup some code or it may be more extensive. Carousel can be added incrementally.
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. Carousel 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 Carousel 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.
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 Carousel 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
Carousel promotes a clean architecture by separating development roles and concerns. As has already been remarked Carousel makes business logic stand out by removing plumbing code. Carousel 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 may mean that an application must cope with intermittent connectivity.
Carousel not only supports this capability but provides sophisticated mechanisms for handling remote communications, routing and fault tolerance. Added to this is Carousel'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. Carousel stylesheets facilitate this rebranding.
Within Carousel 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 Carousel 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 object (more content and less overhead as requests are amalgamated).
If you were logged in you could rate this article or add a comment.
