cool stuff
$Id: index.html 135 2006-01-09 20:31:49Z christianc, v135

Architecture - The Big Picture

The Barracuda Presentation framework is built as a series of layers that depend on the Servlet 2.2+ API, each of which can be used independently of one another. In terms of audience, Barracuda definitely aims at the Java Developer end of the spectrum (with the idea that tools integration will ultimately make the approach more accessible to Page Author types).

At the highest level, the Barracuda architecture can be summarized by the following diagram:

arch_overview.gif (20966 bytes)

The key features of Barracuda are summarized here:

  1. Client Capabilities - Automatically identifies client capabilities (browser type, target locale, etc).
  2. Event Model - Maps client requests to first class event objects; dispatches events to all interested listeners; guarantees that an HTTP Response is generated.
  3. Form Mapping & Validation - Converts HTTP Form parameters into first class Java objects and provides a powerful validation mechanism to verify them.
  4. XMLC - Compiles HTML, WML, and XML documents into DOM template objects that can be manipulated programmatically.
  5. Localization - Automatically creates localized versions of the DOM templates for additional locales. These templates can be loaded based on a target client locale.
  6. Component Model - Uses familiar UI Widgets with strongly typed Swing-style MVC interfaces to dynamically populate the DOM templates with data. the DOM can then be rendered and returned to the client browser.

A detailed explanation of these areas follows:

  1. Client Capabilities - Barracuda begins by identifying the client's capabilities. In particular, it can  determine:

    • client type -- what kind of client are we dealing with (NN, IE, etc) as well as the specific version of the client
    • client scripting capabilities -- what kind of scripting is supported (Javascript, VBScript, WMLScript, or None) along with the specific version information
    • target output format -- what kind of output the client expects (HTML, WML, XML, etc) as well as the specific version of markup supported
    • target client locale -- the client locale information

    This information is available throughout the entire request-response cycle, making it easy to perform custom processing based on a client specifics.
     

  2. Event Model - The Barracuda event model is all about routing -- it's responsible for turning HTTP Requests into first class event objects, dispatching the events to interested parties, and then making sure that an HTTP Response was generated. There are a number of specific features:

    • makes it easy to implement Model 2 style flow control by utilizing a 2-phase dispatch loop in which all Request (Control) Events are processed first, followed by all Response (View) Events.
    • allows for true event driven programming on the server since events are first class Java objects (not just strings or method names) and any event can have multiple listeners
    • event handlers can be implemented using inner classes, just like in Swing
    • integrates with the component model, meaning you can add listeners to components and your server-side event handler code will automatically get invoked when an action occurs on the client
    • events are hierarchical in nature, making it very easy to make an application secure (by controlling what events can be fired without needing to modify the actual event handler code) and robust (by ensuring that a response will always be generated, even if the developer forgets to handle a view event)
    • the model is fundamentally scalable -- event handler instances are lightweight and short-lived  (lasting only for the duration of a req-resp cycle) and event dispatching is fast (no reflection / introspection)

    As a final note, the Barracuda Event model is based on interfaces, making it fully pluggable (you could easily substitute your own event dispatching mechanism if need be). In addition, while the model is tuned for the HTTP Req-Resp paradigm, it could also be integrated with other non-response based protocols (ie. SMTP, JMS, a 3rd party scheduling system, etc).
     

  3. Form Mapping & Validation - Once the Event Model has routed control to the proper location, it is often necessary to examine a client's input parameters before actually generating a response. This is where Barracuda's Form Mapping & Validation layer comes into play:

    1. easily map HTTP Form parameters into first class Java objects based on key name and data type (String, Boolean, Integer, Date, Long, Short, Double, Float)
    2. provide default values if an expected parameter is not present
    3. provide a number of prebuilt validators (NotNull, ValidType, Equals, MaxLength, MinLength, Range, Digit) to handle common validation tasks in a reusable fashion
    4. support the the notion of custom validators to express specific business logic validation requirements
    5. allow for validator aggregation, by which any number of simple validators can be used as building blocks for more complex validation behavior
    6. support for  nestable validation exceptions, making it possible to catch either the first exception or all exceptions on a collection of data

    These features make it easy to get data back from the client in a form that is more easily handled on the server.
     

  4. XMLC - Once we have converted data that came from the client into something more useful than raw String data, we usually need to respond in some fashion (ie. the Do-Something-on-the-Server phase). If we are following the Model 2 pattern, this might involve updating some kind of "Model" via JDBC, RMI, EJB, etc.

    Barracuda offers no help yet imposes no restrictions on what you do in this stage. Instead, it waits for the Render-a-Response phase that inevitably follows. This is the point in which we finally generate a page (or "View") in response to the client's HTTP Request. Barracuda has a lot to offer in this area, and it all starts with a tool called XMLC.

    XMLC is a tool that generates DOM based template objects from HTML and XML documents. Unlike traditional template approaches (JSP, WebMacro, Velocity, etc.) which require you to embed programming logic in the UI markup (aka "Pull-MVC"), XMLC allows the developer to manipulate a template programmatically (aka "Push-MVC"). There are a number of distinct advantages:

    • provides excellent code-content separation -- the presentation markup is physically decoupled from all programming logic used to manipulate a page (each is stored in separate files)
    • this paradigm mirrors the dual roles (Designer vs. Developer) prevalent in real-world webapp development and benefits both parties in the dev process
    • for the designer...
      • guarantees the template documents will always be valid, well-formed markup
      • this makes it much easier for a designer to create and maintain the documents using standard interactive design tools
      • furthermore, a collection of template source documents can continue to function as a working mockup of the application
      • in addition, the designer can make changes to the presentation layout without involving the developer
    • for the developer...
      • the developer can make changes to the business logic layers without involving the designer or impacting the presentation layout
      • the developer can create more portable code by coding against well defined industry standard DOM interfaces (ie. w3c.org)
      • this approach supports multiple document types (HTML, WML, XML, etc...anything that can be read as a DOM)
      • compile time parsing of HTML/XML document offers a significant performance benefit for complex pages.
      • XMLC's Lazy-DOM support further improves performance by only creating DOM nodes for those portions of the template which are actually modified dynamically
    • clean separation of roles promotes full parallel development -- the designer can focus on design and the developer can focus on programming logic. Neither has to worry about interfering with the other
    • enforces good development practices -- developers cannot create KLOCs of unmaintainable presentation code like they can with JSP; corporate developers like this enforcement (Merck and GE are examples of corporate IT shops that have selected XMLC for the natural policy of markup/Java separation)
    • offers advanced compilation features
      • supports runtime auto compilation if markup changes in original doc are detected.
      • supports runtime classloading if new DOM class template is detected.
      • factory methods make it possible to implement one DOM class template interface with multiple, dynamically selected implementations.

    These features combine to make for a very powerful templating mechanism that is not subject to many of the limitations found in more traditional templating approaches.
     

  5. Localization - Barracuda leverages the strengths of XMLC to provide a unique and innovative solution for Localization. Typically, when one wishes to localize a template driven application, one either creates localized versions of all the templates (efficiency at the expense of maintainability), or one dynamically localizes both text and data in a page for every given request (more maintainable, but at the expense of efficiency).

    Barracuda looks for a better solution, one that provides the best of both worlds -- we need something that is efficient (ie. we'd only like to localize static text once for each template) and yet at the same time maintainable (ie. we don't want to have to manage separate localized versions of each template). The solution is elegant.

    • Barracuda uses the Ant build system, allowing us to provide a custom XMLC taskdef that not only compiles the *ML template (ie. Foo.html) to an XMLC object (FooHTML.class), but also looks for the presence of a master properties files associated with that template (ie. Foo.properties)
    • the master properties file can be used to identify the portions of the template that map to "static-but-localizable" text
    • the taskdef then looks for matching localized properties files that follow the locale naming convention (ie. Foo_es.properties). If found, additional templates (ie. Foo_es.html) will be created from the master template, with the localized text substituted in. These too will then be compiled to XMLC objects (ie. FooHTML_es.class)
    • Barracuda provides a custom DOM loader which can load an XMLC DOM template based on a target locale (ie. the programmer specifies "FooHTML.class" for a target locale of "es" and receives a reference to "FooHTML_es.class"
    • the DOM loader works on the same principle as Java's ResourceBundle class, so if a particular template is not available (ie. language "es", country "CL"), the next closest match will be used.

    This approach makes it very easy for the programmer to select a localized DOM template for use in the rendering process without having to jump through any special hoops.
     

  6. Component Model - Once the developer has loaded the appropriate "View" template, the next step is to dynamically populate the DOM structure with data. Unfortunately the DOM interfaces are rather low-level and tedious to program against (especially for complex structures like Lists and Tables). This is where the Barracuda Component Model comes into play.

    The basic idea behind the component model is that you can create a hierarchy of components which are each bound to various portions of the DOM hierarchy. Now rather than manipulating the DOM directly, we can put the data in the components and then render them. The components are intelligent enough to to render the data properly into the DOM structure. There are a number of specific features:

    • at the most basic level, Barracuda components can be viewed as UI Widgets that are similar in many ways to what you find in Swing:

      • any component may contain other components
      • the primary responsibility of components is to render data into the portion of the DOM to which they are bound, and to render all child components
      • there are a number of basic components (BInput, BToggleButton, BAction, BLink, BText, etc) that all extend from a base BComponent
      • there are several more advanced components (BList, BSelect, BTable, and BTemplate) that provide strongly typed MVC interfaces, just like you'd find in Swing
      • all Barracuda component models may return multiple data types -- Strings, DOM Nodes, or other BComponents. This is strategic for supporting component aggregation.
      • there is no framework imposed lifecycle -- you can keep components around for as long or as short a time as makes sense for your domain. In other words, you can create/destroy them repeatedly for every render cycle, or you can cache them on a per-session basis. The developer is not locked into any one approach.
      • similarly, there are no imposed state restrictions -- the framework does not force you to take any particular approach to manage component state. You can persist component state where you wish when/if you need to do so.
      • some Barracuda components offer event model integration -- by adding an event handler the server can be automatically notified when a client gesture occurs. For the developer the process appears seamless, just like in Swing.

    • Barracuda components are also different from Swing components in many ways:

      • they are modeled on the data rather than the UI functionality associated with that data (ie. instead of having multiple components like JLabel and JTextArea, there is one BText component which can render text into many different types of DOM nodes. Similarly, there is one BList component that can render list data into many different markup structures)
      • in addition to having well defined Model interfaces, all Barracuda components must also be bound to at least one View on the DOM.
      • Barracuda components are more concerned with data than layout, since layout information is typically encapsulated in the DOM template
      • as such, they are extremely lightweight (because they don't have much information to keep track of)
      • they use pluggable renderers to render markup appropriate to the DOM template type (ie. HTML, WML, XML, etc.)
      • this allows for highly intelligent rendering; we can take into account the type of node to which a component is bound and render the data accordingly
      • Barracuda components also have to address component aggregation/reuse differently, since the code-content separation means we need more than just class files to create a reusable component -- we need an  accompanying DOM template, plus static resources that might be associated with it (.gif files, etc).

    • While most of the Barracuda components extend the "Push-MVC" model necessitated by an XMLC based approach, the BTemplate component enables "Pull-MVC" as well.

      • the BTemplate component parses the template looking for "directives" (stored either in the template or in a separate properties file)
      • these directives are then mapped to data in a manner similar to that of taglibs (except of course that the model can return more than just String data!)
      • this approach provides better designer-developer decoupling, while still leaving the developer tremendous freedom in terms of how to provide the requested data
      • this effectively "componentizes" the template engine approach so its just another tool in the developers bag of tricks -- freely available when necessary, yet conveniently avoidable when not. In other words, this doesn't lock you into using a template engine for an entire page/app the way most template approaches do...you can use it where it makes sense.

    The result of all this is a component framework that is inspired by Swing yet fully accounts for the intricacies of code-content separation and the HTTP Req-Resp paradigm. In addition, it supports a full spectrum of server side development methodologies, ranging from "Push-MVC" to "Pull-MVC".

For a more detailed explanation that expands on these details, you may want to refer to Barracuda vs Struts or drill into the docs for individual subpackages.


Last Modified: 2006-01-09 21:31:49 +0100 (lun, 09 jan 2006)