Everybody,
I'm going to write an article on this for the Journal, but here's some
high level
discussion of why we're starting to see promising interest in the fact
that we've
integrated Barracuda into EAS 4.1.
First, Barracuda is based on XMLC... so here are a few key points about
xmlc.
-
xmlc is a presentation technology. So is JSP. Both employ different
strategies for generating HTML dynamically, such as a table of rows with
customer addresses.
-
jsp uses a "pull" strategy:
-
java, taglibs, etc., are introduced into an HTML file ("page"). The
file is compiled into a Java class.
-
the "pull" refers to the fact that java code inside the page "pulls" new
content into the page by, for example, accessing a java bean representing
some business logic.
-
xmlc uses a "push" strategy:
-
the html document is compiled into a java class by the xmlc compiler.
It is captured as a hierarchical tree data structure that can be accessed
according to a W3C specification known as the Document Object Model (DOM).
-
the "push" refers to the fact that Java code in servlets "pushes" new content
into the DOM, which is later converted by xmlc libraries back to HTML,
then sent back to the client.
-
There are plenty of reasons why we believe xmlc and the push strategy is
_way_ better than the JSP strategy. They include:
-
no matter what, java code and html never meet. The implication is:
-
it's easier for HTML designers to restructure or update presentations
-
java developer's can't become control freaks and start shoving java inside
the html
-
it's much easier to maintain and rework web presentations using xmlc
-
it's easier to build language-independent presentations (e.g., french,
english...)
-
xmlc guarantees that the updated dom will generate well-formed html or
xml. jsp cannot guarantee the same.
-
to approximate the value above of xmlc, a software architect must make
heavy use of additional capabilities that have been added to jsp (to stop
the bleeding), such as jsp taglibs. BUT, the fact is that they can
never enforce the use of these capabilities because engineers will often
take shortcuts to get their jobs done. And even if they do follow
these guidelines, it's still not a pure separation of Java and mark-up.
And now about Barracuda...
-
barracuda is a presentation framework. so is something called "Struts."
-
Barracuda does for XMLC what Struts does for JSP
-
Both are submissions to the Sun JSR-127 "Java Faces"
-
A presentation framework standardizes the standard needs of Web presentation
development.
-
Client type detection ("what kind of device is making this request?
NS, IE, Nokia, J2ME? What is the client's perferred spoken language?)
-
Localization - mechanism for displaying page in preferred language.
-
Form Valiation - process of ensuring the client filled out the form according
to some set of rules
-
Event Handling - mechanism for routing the push of a particular button
to any server-side code that wants to deal with that event.
-
and there's more...
-
Presentation technologies, such as xmlc and jsp, punt on these topics.
They instead focus on the original question of "how do you glue markup
and logic together?"
-
Barracuda versus Struts
-
There are two major reasons, albeit they are somewhat prejudice ;) why
Barracuda is better than Struts.
-
Barracuda is mimicked after the JFC/Swing MVC model - Ignore MVC for now.
Just know that the Swing model is very popular and critically acclaimed.
It does a very, very good job of describing how an application should handle
a request and generate a presentaton response.
-
Barracuda is built on an XMLC foundation. - The result: Barracuda
inherits all the goodness of XMLC (versus JSP) as described above.
-
Struts is based on JSP. As a result, it's must first insulate the
developer/designer from the weaknesses and inconstitent capabilities of
JSP development in order to present a standard environment that compose
a presentation framework.
-
There are a number of other reasons including the comprehensive state of
Barracuda development compared to Struts. One of them is the "tacklebox"
analogy used by Christian Cryder in defining the Barracuda architecture.
Tacklebox refers to the fact that if you are developing with xmlc and all
you want to use is Barracuda's localization capabilities, then just use
it and do everything else your own way. This is a very nice feature
for those who don't want a heavy handed, policy rich presentation framework
or for those who simply want to get their toes wet until they become more
comfortable with the rest of Barracuda.
Anyway, that's enough for now. The good news is that Barracuda/XMLC
is very popular with system/application architects. These people
are closer to decision makers than the engineers in the trenches who would
rather the HTML designer folks just go away.
I'm also putting together another paper on Barracuda/XMLC that deals
with different scenarios that a potential EAS 4 customer may be dealing
with... comparing the JSP solution to the XMLC solution in the process.