Re: JBoss + EJB3 + Liferay

Shawn Hartsock wrote:
> First, I'm not driving all the technology choices at my company, so, I
> can't take all the credit or blame for them. I did participate in the
> decision making process.
> 
> The choice of Velocity was driven by Dreamweaver. It turns out you can
> get a plugin for Dreamweaver to use Velocity...
> http://velocity.gilluminate.com/ ...that means we don't need to hire
> web designers that know JSP. Web designers get to stay in their
> comfortable Dreamweaver bubble and Java developers get to work in Java
> objects and frameworks without dropping to JSP.
>

Velocity has been around a long time.  A lot longer than JSP and has 
many fine features that recommend it OVER JSP.  For one scalability on 
Tomcat (Jasper is a weakpoint of Tomcat) and cacheability (it can render 
directly to a string).  Velocity also has support in many areas 
including those beyond the web (we use it for config file templates). 
On the other hand I suspect you'd find Tapestry meets your design 
separation and makes cleaner code.

> That was the theory anyhow. It seems to work out in reality that...
> the web person only needs a superficial understanding of Java Portlets
> and they do need to be able to read some of the code. The level of
> necessary skill there is quite reduced in favor of much more acutely
> developed design and javascript skills. So in other words you could
> hire a PHP whiz to do your views... in theory.
> 

We did our whole site in PHP ;-).  Java developers are too expensive ;-)

> DWR was chosen because it generates _all_ the javascript for a remote
> method for you. It also turns out to be the only framework that is
> currently secure against certain types of cross-site-scripting and
> javascript hijacking attacks...
> 
> http://www.cgisecurity.com/articles/csrf-faq.shtml
> http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf
> 
> ... but the deciding factor was actually based on the DWR 2.0
> Annotations. You build DWR services using annotations... and you
> annotate POJOs which are turned into JSON objects. The DWR then
> generates JavaScript frameworks for you to call on and use your POJOs
> from Javascript land... and then we usually mix in some scriptaculous
> and get a delicious soufflé of POJO + Velocity + Ajax goodness.
>

DWR sound cool.  Never heard of it.

> Liferay was chosen as the portlet because at the time of the project
> launch it was the most mature free portal out there.
> 

Liferay is a very popular portal software.

> Same logic applies to JBoss... mature, free, out there...
> 
> The theory was that if we stuck with the JSR standards we could move
> the project to another database, application server, portal later if
> we needed to.
> 

A nice theory.  In reality the JSR for portlets is spartan and to do a 
really scalable system as far as persistence you'll have to use SOME 
extensions.

> It looks like after about 18 months of effort we'll be going to
> production with this mix of technologies and the project will
> transition to maintenance mode in the next few months.
> 
> As far as cats and skinning them... yes I agree there is definitely
> more than one way to do it. If the language is Turing complete it can
> by definition be made to do anything any other language can do...
> including writing another language.
> 
> Still, I've decided that jBPM is definitely the "Right idea"(TM)
> because it represents a real innovation removing the flow of control
> from laborious flow control constructs and putting them into a Graph
> Oriented Programming environment. I think the reason that being able
> to draw flow control is such a big deal is that it is very likely more
> natural to think this way. But not just that... thinking from graph to
> code forces the programmer to think in re-usable modules.
> 

I think it is a good idea, albeit hiring for that one and the learning 
curve is going to be a bit painful.

> It is so very important to working in large groups for the programmer
> to be able to really see how each functional component can get
> re-wired into a new whole. This type of thinking doesn't come
> naturally to the developers I normally work with. I usually have to
> coax it out of them. It is not a technology problem, it is a thinking
> problem.
> 

Yeah, maybe the IDE will help but the copious amounts of XML don't help 
them either :-)  (there wasn't the IDE when I learned it and my 
fingertips still have nightmares and I have a shift-. and shift-, twitch)

> For example, MIT released a graphical programming system (
> http://scratch.mit.edu/ ) for children. Programming constructs and
> concepts are represented as graphical elements. This gives computing
> constructs a different face without watering them down any.
> 

Yeah and theoretically you can create a VM that runs off UML...However 
boy I'd rather type...and screw all you visual learners!  Text4ever

> What the GOP tools like jBPM offer is a different aspect of program
> visualization, (just like the kids and their Scratch programs). I've
> used jBPM + the GOP XJC tool for building/browsing XSD to create
> applications where we can visualize the flow of control of a process
> and the structure of  the data used by the process together.
> 
> I think that the GOP + jBPM/BPEL + SOA suites actually buys us a new
> way to think about what we do with our programming languages. There
> really are a few Good Ideas (TM) in there... I just find it tough to
> know which way the wind is blowing.
> 

I think SOA is really just a bunch of marketing blow for modules + registry.

> As far as companies not adopting EJB3 I can see that for legacy
> projects but for new development... I would think they would want the
> AOP development models to improve productivity. It's just so much less
> painful not having to do all the sit-ups...
> 

When EJB3 was being developed I had a fight internally that it needs a 
name other than EJB which means "suck" in most developers minds.  EJB3 
is everything to Spring that Spring was to straight EJB...but most 
people got burnt enough to not try it.  I mean you can literally do 
XML-less/JNDI-less programming, get free declarative transactions, more.

Some other choices that were options:  JBoss Portal.  The 2.4 is still a 
little glitchy and buggy but it is a decent offering and probably 
integrates a little better with some of the tech mix you chose.  Less 
industry support than Liferay.

Glassfish.  Glassfish (Sun's open source) is the contender JBoss wasn't 
counting on.  Sun could always be relied upon to suck and produce at 
best mediocre software (BEA/Intel's 1.4 JVM was much better than Suns on 
multi-processor machines especially).  However something has changed at 
Sun beyond embracing open source rather than just blowing hot air about 
embracing open source....they got their mojo back.  Now if they could 
stop playing stupid version number games and renaming things... 
Glassfish is full JavaEE (formerly J2EE) unlike JBossAS.  On the other 
hand JBossAS has seen more real production deployments and I'd bet the 
clustering is more mature...albeit to tune JGroups you need to know Bela 
Ban ;-).  JBossAS has had some really horrible bugs (multiple memory 
leaks esp PERM space memory leaks with EJB3) and is undergoing a 
transition to a new RHEL/Fedora style model under Red Hat.  Its possible 
it will all work out, and I wouldn't jump ship yet but if you're looking 
for a good "just in case" or negotiation piece...Glassfish is my 
recomendation.  IMO, Look past Geronimo/WebSphere which never 
materialized as the threat that it imagined itself to be, JonAS which is 
what EU grant money can do unchecked, Weblogic is still decent but BEA 
is not a healthy company...albeit an unhealthy company whose brains all 
left for google but which has a lot of cash, WebSphere still is really 
really big and really tied to IBM's "platform" and horribly unpleasant 
to debug on.

Seam is an interesting option.  It is JSF but EJB3ized and integrates 
with JBPM out of the box.  On the other hand it is AJAX in the "cool 
controls" sense but not the "client rules" sense.  IMO, Its more like 
Web 1.5 than 2.0 if you will.  It integrates more cleanly with EJB3 and 
jBPM.  Since you're already on JBossAS, jBPM -- you might consider that 
JBoss Portal, JBoss Seam would give you a single vendor support solution 
possibly down to the OS level.  This is a unique situation that RH finds 
itself in that previously only IBM could do realistically.

Flex - Adobe's tech (my pal James Ward is coming to speak on it). 
Recently open source.  Compiles to flash.  Don't do it if you have dial 
up customers, but this is AJAX jit-ed and REALLY cross browser (because 
flash is) and on Linux/Windows/Mac.  However it is very naughty in that 
it is a proprietary platform (Flash).  And you're tied to Adobe's wim. 
albiet the Flex IDE (eclipse plugin) has a rather nice debugger and it 
is far more RAD than GWT or most of he stuff out there.

The SOAP services...  I get why you'd tend to do this (esp with portlets 
and WSRP), but I caution you against too much IO.  Make local calls 
where you can.  SOAP doesn't buy you "flexibility" it.  The XML 
interface is just as fragile as the Java interface.

Also carefully design your persistence layer: 
https://rhstack.108.redhat.com/articles/2007/02/09/design-issues-in-high-performance-transactional-applications-using-Java-and-Linux.html

-Andy

-- 
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.

_______________________________________________
Juglist mailing list
[email protected]
http://trijug.org/mailman/listinfo/juglist_trijug.org