Barracuda - Surveying the Landscape
barracuda.gif (11456 bytes) The purpose of this document is to briefly survey the server-side presentation layer landscape to identify other frameworks that share similar problem domains to those addressed by the Barracuda MVC and Component frameworks. Additional documents will provide more detailed analysis of the specific projects mentioned here.
  1. Changes History
  2. Core Approaches to Content Generation
  3. Barracuda Competitors
  4. Barracuda Non-competitors
  5. New Additions
  6. Conclusion

Caveat Emptor! This is all just our opinion! We have tried to be accurate by looking at web pages, reading documentation, and even contacting the authors with specific questions, but its always possible that we blew it somewhere. In addition, these frameworks change and its hard to keep everything up to date. Consequently, if you see something we missed, or if you would like to provide a more accurate review of a specific framework, please let me know. I will do my best to update the document as soon as I can.

NOTE:  If you feel your favorite approach is not adequately represented here, the best way to get it updated is to take a few minutes and actually submit a better summary.


Changes History

  • 02/15/02 - Minor correction: WebSphere 4.0x supports EJB 1.1.
  • 11/01/01 - Minor tweaks to note that PowerForms is written in C and Hammock seems to have disappeared.
  • 07/23/01 - Updated the Turbine links; moved Expresso to the Barracuda Competitors section and added some info from Michael Nash; added references to Sitemesh and WebWork, submitted by Mike Cannon-Brookes; added a preliminary reference to Tapestry; added a preliminary reference to Bishop; added some additional information on PwerForms provided by Jose Cabrita; add a reference to Maverick; add a reference to WingS
  • 06/26/01 - Updated WebSphere to reflect J2EE compatibility
  • 02/12/01 - Fix minor mistakes to acurrately reflect BEA as market leader; added comments on WebSphere.
  • 01/05/01 - New Barracuda format.
  • 09/29/00 - Add a reference to Tapestry framework.
  • 09/25/00 - Added reference to TeaServlet template engine; minor text clarifications.
  • 09/18/00 - Created

Core Approaches to Content Generation

Barracuda will support all 3 Java centric server-side approaches to content generation:

  1. Simple Servlets - Servlets have been around the longest--they allow the developer to generate content directly from Java by writting to the HTTP output stream. Disadvantage is that you often end up with HTML and Javascript embedded within your Java code.

  2. Template Engines - Template engines generally take a document centric approach, allowing the developer/page designer to access Java objects from within HTML pages. This is supposed to help separate content from code, however it usually results with a scripting mechanism within HTML, which means that web pages typically become cluttered with snippets of Java code or (worse) some other proprietary scripting language. 

    JSP is the defacto standard when it comes to HTML scripting.  There are other template engines like TeaServlet, WebmacroFreemarker and Velocity.  These last three approaches provide their own flow control mechanisms, so it may be more difficult to leverage the Barracuda MVC framework from within them.

  3. DOM Manipulation - This final approach goes one step further than template engines -- rather than embedding logic within documents, we can access HTML pages directly through the Document Object Model (or through JDOM or XMLC generated DOM). This allows for true separation of content from code, making it possible to keep all the programming logic in one place (the servlet).

    XMLC compiles HTML (or XML) documents into Java objects to provide programmatic "hooks" directly to tags within the DOM, making it easier for the developer to manipulate nodes in the document heirarchy while page designers can focus on the actual look and feel of the HTML.

What we are saying here is that Barracuda does not compete with these fundamental approaches -- it supplements them.  In addition, Barracuda does not require developers to use one approach over another--you can pick the tool that is right for your task.  If you want to use servlets or JSPs the Barracuda framework won't prevent you from doing so. In the same way, Barracuda does not require you to use Enhydra--it will work with any Servlet 2.2 compliant server. 

Of course, we happen to think that XMLC and Enhydra are pretty good solutions, but hey, the choice is yours ;-)


Barracuda Competitors

There are several frameworks we feel do compete fairly directly with the Barracuda MVC and Component frameworks:

  1. Leading Contenders - (In terms of adoption)

    • Struts (Jakarta) - Struts is a JSP centric approach to MVC which is generally viewed as the representative implementation of what Sun calls the Model 2 architecture. Struts is squarely focused on providing a flow control framework for JSP based web apps. It provides a controller servlet, JSP custom tag libraries, and various utilities to support XML and internationalization.

      Struts does not address component composition/reuse as the Barracuda Component framework intends to do. In terms of developer adoption, Struts is probably the leading contender over all other approaches because JSP has the official blessing of Sun, primarily to compete with MS's ASP strategy.

    • Turbine (Jakarta) - Turbine is similar to Struts, although it offers a richer feature set and is intentionally not tied to JSP (they like the moniker Model 2+1). The focus of Turbine is to create a collection of reusable components aimed at easing server side development. Functionaly speaking, Turbine probably offers the richest feature set available, with over 200 classes in the toolkit. The project scope seems somewhat overbroad, however, resembling a cluttered collection of sometimes not-so-related tools. For instance, Turbine provides MVC flow control, integration with Object Relational Mapping tools, a job scheduler, localization services, caching services, and many many other features.

      In addition, Turbine offers extensive integration with template engines like Cocoon, JSP, ECS, WebMacro, Freemarker, and Velocity.

      In sum, Turbine is quite powerful, but seems to address a much wider domain space than the focused vision of Barracuda. I think Turbine is probably the leading contender in terms of functional offerings. Like Struts, Turbine also does not address component composition/reuse.

  2. Component Frameworks -

    • Hammock (Oop) - Hammock takes a unique approach to building web based user interfaces, using a component model similar to Swing's, which then renders itself to actual HTML. This development model facilitates object reuse also provides familiar client-server style MVC flow control. Furthermore, Hammock's JFramework claims to add additional features like the ability to decouple component objects from business rules, OR Mapping, and performance increases.

      Hammock is a commercial product with (apparently) strong backing, and appears to be the only real framework attacking reuse problems through component composition.  However, Hammock does not seem to facilitate code/content separation the way XMLC does. [NOTE: Hammock got purchased by someone, and seems to have disappeared from the market]

    • WingS - WingS is probably the closest thing I've found to Hammock that is open source. Unfortunately, I think both WingS and Hammock make the fatal mistake of trying to mirror the Swing APIs too exactly; the result it that they fail to properly provide the necessary separation between UI (ie. *ML template) and programming logic (to manipulate/populate that template). The mailing list traffic for this project is almost nil.

  3. Other Approaches -

    • WebWork - WebWork is a web application framework for J2EE. It is based on a concept called "Pull HMVC" (Pull Hierarchical Model View Controller). The basic idea is to separate the site programmers' and site designers' tasks.

      It has a small API and easy to use tag library in order to make it as easy to use as possible. It supports the notion of actions that are just JavaBeans. This means that they have setX() methods for incoming parameters, an execute() method to perform the action, and getX() methods to retrieve the result data. This ensures that all actions only contain the code that is required to perform the logic.

      The tag library has also adopted this philosophy. They only provide tags to extract and iterate over the result data so that formatting the output as HTML, WAP, or what ever is as straight forward as possible.

    • Expresso - Expresso seems similar to Turbine in many ways, offering a plethora of functionality including for security, connection pooling, database access, email connectivity, job control, health check, logging, etc.  It also offers mail based event notification, however, this is more applicable to work-flow systems than interactive MVC needs. Like Turbine, Expresso is much more broadly focused than just the presentation framework domain.

      Expresso addresses MVC with its "Controller" object and package - this is a finite-state style architectured object similar in many ways to a stateless session bean in EJB parlance (and deployable as such) that is specifically intended to implement the "C" in an MVC architecture. Also, the Expresso XML project allows these "Controllers" to be rendered in XML & transformed via XSLT to any UI desired.

      With the new 4.0 release Expresso integrates with Struts.

    • Tapestry - Tapestry is an interesting framework that positions itself as an alternative to JSP. Interestingly, its one of the few approaches that recognizes the value of a component model, although their definition of such is quite a bit different than that of Barracuda. Based on a cursory review of the documentation, it looks like this approach is similar to that of taglibs--you reference a "component" in from within the template, but rather than being backed by a JavaBean or Taglib object, the reference is handled by a "component" which is defined through in an XML descriptor.

      Interesting approach, but we need to better understand the details before we can fully evaluate it in terms of strengths and weaknesses.

  4. Scriptable Template Engines - Basic template engines like JSP and TeaServlet will not really compete with Barracuda MVC because they do not provide any built-in flow control mechanisms. There are several proprietary template engines, however, which do offer MVC implementations.

    • Freemarker (SourceForge) is a template engine where the HTML "template" page is manipulated programatically through a simple scripting language embedded in the template.

    • WebMacro employs a similar approach, using a lightweight scripting language within the document content.

    • Velocity is another template engine which uses the same fundamental idea of embedding logic within HTML via scripting.

    Given their use of scripting, I'd consider these frameworks similar to JSP.  However, each of these approaches add flow control mechanisms -- the developer is responsible for putting data elements into a "model" by key name, the designer is responsible for putting the key names into the page, and the framework tries to magically glue things together (find the key names in the page, match it to the data in the model).  Consequently, each framework provides a (very simple) implementation of Model 2 architecture.

    This integration makes life easier for developers in simple scenarios, but it's not not very scalable or extensible as functional complexity grows. In addition, because the flow control is tightly coupled to the template engine, it is difficult to use any other MVC framework. This limitations will probably prevent widespread adoption.


Barracuda Non-competitors

There are also projects which aren't as similar as they might appear at first glance:

  1. Application Servers - many products are really just Application Servers, which generally implies that they conform with known specifications like Servlets, JSP, EJB.  These products are not considered competitive if they do not offer additional flow control frameworks. Major examples include:

    1. WebLogic (BEA) - WebLogic is actually the industry leader in terms of market share, and it enjoys widespread adoption among developers. Everything you'd expect in terms of API functionality: J2EE, Servlets, JSP, etc.  There is a personalization engine, similar to Enhydra's Brock effort, but from what I can see, however, if offers nothing aimed at the presentation layer that might be comparable to Barracuda.  Please correct me if I'm wrong here...

    2. WebSphere (IBM) - IBM is the number 2 appserver (behind BEA) in terms of market share. WebSphere 4.0 uses the Apache HTTP server and a modified version of JRun for the Servlet Container. It supports J2EE 1.2 (Servlets 2.2, JSP 1.2, EJB 1.1, etc). While there seems to be some simple value add in terms of user session/state management, the main play seems to be in terms of integration with other IBM products and tools. Please correct me if I'm wrong here...

    3. iPlanet (Sun) - As with WebLogic, Sun's iPlanet offers full featured API  support (J2EE, Servlets 2.2, JSP 1.2), SSL and LDAP functionality, and an integrated personalization engine. Once again, however, there appears to be nothing aimed specifically at the presentation layer. Please correct me if I'm wrong here...

    4. Resin (Caucho) -   Resin is really just a really fast Servlet 2.2 Container that also can do load balancing. It supports JSP 1.0, and uses a templating mechanism called XTP to separate JSP code from HTML. XTP forms the basis for Resin's Model 2 support, but they don't really have an MVC framework per se.  Resin provides XML / XSL parsers, and is working on basic EJB 1.1 support.  They do take a relatively unique approach in compiling Javascript to Java bytecode, although this seems somewhat tangential to the product roadmap. 

      Overall, Caucho seems like a relatively small shop with a clean product that performs very well. But they don't offer much in terms of a presentation framework.

    5. Orion Application Server - Like Resin, Orion is primarily just an app server. Full featured, low-priced, the Orion folks claim full support for J2EE (EJB 2.0, Servlets 2.3, JSP 1.1, etc.). In addition, they offer the expected load-balancing for scalability with session state replication for failover. Finally, they have created GUI tools to make it easy to deploy EJB, War files, Tag libraries, etc.

      The company seems further along than Caucho, and the product appears to have a very strong reputation among developers. Still no support for any kind of presentation framework, however.

  2. Document Transformation Approaches -

    • Cocoon (Apache) - Cocoon describes itself as publishing technology built on W3C standards: DOM, XML, and XSL. While Cocoon does recognize the need to separate applications into layers (they identify content, style, and logic layers), the real development thrust is really document manipulation: create an XML document, process the file, and then render it using XSL. While certainly interesting, Cocoon really resides at a much lower domain layer than a presentation framework like Barracuda.

    • Sitemesh - Sitemesh is a web-page layout system and web-application integration system to aid in creating large sites consisting of many pages for which a consistent look/feel, navigation and layout scheme is required. SiteMesh intercepts requests to any static or dynamically generated HTML page requested through the web-server, parses the page, obtains properties and data from the content and generates an appropriate final page with modifications to the original. This is based upon the well-known GangOfFour Decorator design pattern. Basically it uses Servlet Filters and an extremely fast page parser to 'decorate' any HTML page, generated in JSP or not. There is immense flexibility in how decorators are mapped and chosen, and you can have the same decorator decorating perl, jsp, asp and php pages in one site (making a common look and feel across languages!).

    • Maverick - Maverick is a minimalist MVC framework which basically focuses on allowing the developer to write the controller and then generate the view using a technology of their choice (JSP, Velocity, or XSLT). Maverick's MVCishness seems fairly loose--the framework seems primarily interested in presenting JavaBeans models directly to XSLT transforms as DOM interfaces. Keep in mind that my understanding of this framework is still pretty shallow, so you may wish to evaluate it more fully yourself.

  3. Element Constructor Set (Apache) - The Element Construction Set (ECS) appears to be a tightly focused utility whose primary purpose is to make it easier to write HTML documents by encapsulating the details of HTML within a Java object package. In other words, to write HTML, the developer creates an HTML object and then iteratively sets properties.

    While this appears to be an elegant solution for a very specific problem domain, the niche ultimately appears to have little overlap with Barracuda.

  4. Sash Weblications (IBM) - Sash basically appears to extend client side scripting languages to allow scripters to create "weblications" that extend beyond the browser--running on the Windows desktop--without having to know C++, VB, or the COM object model. This is accomplished by a one time install of the Sash Weblication Manager, which provides runtime, security, and deployment services to the client scripted "sashlets".

    Overall this really appears to try and do for JavaScript what JavaPlugin/Applets do for Java.  Interesting, but really a completely different arena than Barracuda.


New Additions (still to be researched)

There are also some products / frameworks which we have heard about but haven't thoroughly researched yet. If someone wants to provide a summary of these, I'd be most appreciative.

  1. PowerForms - David Li tipped me off to a JavaScript Framework called PowerForms (part of Bigwig project; note that PowerForms is written in C, according to Eric Chan, so it may not be as useful to Java developers). David's description "it defines a form description language in XML and a compiler to compile the description into JavaScript. The activity is close to W3C's Forms specification.  The PowerForms' model fits really well with XMLC." Sounds like it's at least worth looking at. Jose Cabrita provided some additional information by describing the basic dev process:

    1. Write/Edit the normal HTML form, with Field NAMES, with favorite HTML Editor
    2. Write/Edit Validation specifications, in a customized/specialized language:
      • Compact/versatile/complete language XML-like
      • Specify named validation expressions: Can use PERL regular expressions or own syntax.
      • Bind/associate each expression to corresponding Form field: (Field Name<->Expression Name) == Validation Rule
      • Can specify conditionals
      • Can relate different Fields to one another (ie. interdependencies between fields)
      • Can specify run-time "filtering" of list of Field values (in SELECT lists, etc)
      • Based on solid theoretical grounds (Set Theory)
      • Also allows use of Applets in Form (to perform unusual/weird validations in case one might need it).
    3. Validation specifications can be placed:
      • Inside original HTML Form (no touching of HTML code is required). Complete separation of Rules/Design.
      • Can be placed in a separate file/library/URL
    4. Use POWERTRANSFORM compiler:
      • Validation specifications are parsed and compiled to portable JavaScript code. Implements own finite-state automatons. Depends only on "standard" Browser capabilities.
      • Original HTML Form is parsed and a new one is generated. Transformed HTML Form will automatically contain:
        • Original HTML code
        • Event handlers automatically added to appropriate Fields, calling appropriate automatons.
        • Compiled automatons
        • User messages/Error dialogs/messages
    5. Usual testing phase done (same as steps 7/8)
    6. Deploy.Client will only see the transformed HTML Form, not original one.
    7. Keep original HTML and Validation specifications.
    8. If changes needed later: Back to steps 1 or 2. Edit. Recompile. ReTest ReDeploy.

  2. Bishop - yet another template based approach, in which the developer writes scripts which are executed when the broswer requests a resource. Bishop positions itself as the Controller protion of the MVC pattern, with WebMacro being used to generate the views.

  3. Microsoft's ASP+ - It appears Microsoft has rewritten ASP and in doing so they have added something for event handling. This is really outside the scope of Barracuda, since it's neither Java nor open-source related, however, it wouldn't hurt to take a look at this just to see how they've approached the problem domain.


Conclusion

In conclusion, I think the products which come closest to what we are talking about doing with Barracuda are

  • Struts - for it's Model 2 implementation with JSP
  • Turbine - for it's Model 2+1 implementation with everything other than JSP
  • Hammock - for it's hierarchical component approach

We will examine each of these projects more closely to determine the specific strengths and weaknesses of each.

For all the latest information on Barracuda, please refer to http://barracuda.enhydra.org
Questions, comments, feedback? Let us know...
Copyright 1997-2002 Lutris Technologies, Inc. All rights reserved.