$Id: index.html 135 2006-01-09 20:31:49Z christianc $ - $Revision: 135 $
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:

The key features of Barracuda are summarized here:
- Client Capabilities - Automatically identifies
client capabilities (browser type, target locale, etc).
- Event Model - Maps client requests to first
class event objects; dispatches events to all interested listeners;
guarantees that an HTTP Response is generated.
- Form Mapping & Validation - Converts HTTP Form
parameters into first class Java objects and provides a powerful
validation mechanism to verify them.
- XMLC - Compiles HTML, WML, and XML documents
into DOM template objects that can be manipulated programmatically.
- Localization - Automatically creates localized
versions of the DOM templates for additional locales. These
templates can be loaded based on a target client locale.
- 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:
-
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.
-
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).
-
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:
- 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)
- provide default values if an expected
parameter is not present
- provide a number of prebuilt validators (NotNull,
ValidType, Equals, MaxLength, MinLength, Range, Digit) to handle
common validation tasks in a reusable fashion
- support the the notion of custom validators
to express specific business logic validation requirements
- allow for validator aggregation, by which
any number of simple validators can be used as building blocks
for more complex validation behavior
- 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.
-
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.
-
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.
-
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:
-
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.
$Date: 2006-01-09 21:31:49 +0100 (lun, 09 jan 2006) $