martin fowler and jsp evils...

Hi All,
I compiled my notes (below) from a talk that Martin Fowler of design 
pattern fame gave at the local Boulder Java User's Group.  I'm posting 
it here because of his slam of "the evils" of JSP and how it undermines 
architectures that employ solid layering (e.g., between presentation and 
business domain layers).  And, as I've quoted him, he's "seriously 
concerned about JSP taglibs." There were at least 200 people there and 
the guy sitting next to me says, "he's right... I've been using this 
xmlc stuff and it's great..."

So, I'm hoping to get Martin on board with xmlc and the value of 
DOM-based presentation development.  Seeing the posting about 
http://xmlceclipse.sourceforge.net really pumped me up.  This community 
needs folks to beat the drum and get the word out.  xmlc is still one of 
the best kept secrets out there.

Do people realize that Sun updated the SunOne architecture (chapter 8?) 
to say that there are now two types of presentation strategies: embedded 
(JSP) and DOM-based (xmlc/barracuda)?  Unfortunately, their architects, 
for political reasons, could not list xmlc or bararcuda... but you can 
clearly see it's there.

Hope you find my notes of some use... note the preponderance of .NET 
developers in the audience (of a JUG!).    - David
---
I attended Martin Fowler's talk on Patterns for Enterprise Application
Architectures at the Boulder Java User's Group, Thursday, 9 Jan 2003. (A
lot of .NET developers are attending these talks.) The guy is a
wonderful speaker if you get the chance to see him.  He's one of the top
authors on design patterns, well known in the old Smalltalk community
and now at Thoughtworks in Boston.

http://www.martinfowler.com
http://www.thoughtworks.com/

Some of his messages (elaborated later):
1. The focus on patterns is shifting above the Java or .NET
implementation.  Talk patterns now, worry about implementation later.
2. JSP (scriptlets) is the root of all evil, as a major threat to the
benefits of layering. "I am very worried about taglibs."
3. In arch development, focus on excellent layering, then apply patterns
(where they add value).
4. Entity beans are a disaster. O/RM tools have no standard player.  OO
and SQL just don't sync well. Use POJOs (plain old java objects) instead.


POSA: Pattern Oriented Software Architecture
His goal with patterns: getting developers/designers to use a higher
level language when discussing design strategies.

Architecture:
- Everybody wants a definition of what "architecture" means.  He's
decided it's "whatever is important to you."
    -> what are the most important decisions we must get right early on.
- Most important aspect of architecture: "start with layering, then add
patterns where they solve design challenges."
- Three layers that he likes to focus on:
    1. Presentation: web services, html, etc...
    2. Domain: business rules, validations, calculations
    3. Data Source: integration, legacy RDBMS, Rowsets (MS)
- Each layer represents a different set of problems, patterns.
- Business logic (oxymoron) creates different challenges than
integration with SQL.
- Layering is key to "managing the complexity" of enterprise
applications that contain many drivers of complexity
    - business logic that is complex and illogical
        - "give the workers in the Pittsburgh plant an extra day off if 
the Steelers are in the playoffs."
    - UI for many roles
    - multiple users
    - large gigabyte storage, large # of tables
    - integration with other systems

JSPs: He then launched into the evils of JSP and how they threaten good
layering more than any other aspect of J2EE.
E.g., task: turn a dollar amount red if less than $10.  Most often, JSP
developers will stick the business logic in the JSP rather than confine
it to the Domain layer.  It's just too easy to do violate good layering
when using JSPs.


Entity beans:
- they (ThoughtWorks) have stopped using them.
- Can't find any value in entity beans.
      - too hard to develop; slow dev cycle
      - too hard to debug
      - performance sometimes an issue
- They instead use POJOs and JDBC.
      - with POJOs, can use standard debugging tools.
- EJB container still provides declarative transactions and security.
- On Marc Fleury's accent on caching of EJB data: "the OS gets confused
between the EJB cache and the DB cache.  The DB caching is always going
to be superior."
- CMP is only argument for entity beans.  But it's not sufficiently
persuasive.  Yes, CMP is a kind of standard.  CMP, as a defined J2EE
standard, has hindered competitive alternatives. You could call CMP a
standard O/RM tool... but it's not a good "useable standard."

SQL and OO
- don't mix well.
- there are no good, standard O/RM tools.
- Table Module: works well with SQL... great tooling support from Microsoft.
      - This is Microsoft's Dataset/Rowset approach to grabbing a table
as one big object rather than a collection of objects.

Misc:
- Gave a nice talk on 3 patterns:
    - Transaction script: scripting and its limitations, such as
duplication of code and scalability.
    - Domain Model: classic OO style of Java to break things down into
objects. Super robust, but sometimes silly overhead (entity beans).
    - Table Module: Microsoft's approach to fetching and representing
persistent data to the rest of the application (nice tools make this
approach even nicer, but can it scale as much as the Domain Model?)
- mentioned fit.c2.com as a nice complement to JUnit. (I don't know if
that means that it competes with Cactus.)
- favorite IDEs: IntelliJ and Eclipse

--
David H. Young
1.831.246.1692 (cell)
http://www.kspar.net