Re: JBoss + EJB3 + Liferay

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.

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.

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.

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

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.

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.

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.

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.

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.

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...

-- 
--Shawn Hartsock



On 7/2/07, Tim Jowers <[email protected]> wrote:
>
> Hi Shawn, FWIW here's my opinion,
>
>    I think its fairly unique. How is Velocity? Why did you choose this
> stack? I know BEA was pushing jBPM a while back. Not sure what the queue
> vendors (Vitria/Tibco/et al) push. There already were alot of BPM tools but
> IMO BPM is a marketing buzzword as the majority of projects are exactly
> business process implementations. I think the industry moved to portlets too
> for new projects. Refactoring JSP was too much actual work and required
> thinking about what you were doing rather than hacking away a million miles
> an hour. As for AJAX, its almost a requirement to do operational systems in
> a web browser without applets or ActiveX. No responsive operational system
> is possible without some client-server interaction IME because even using js
> with hiddens/iframe/cookies/other caching quickly blows up in IE on the
> average worker's desktop hardware.
>
>    Interviewing a few months back I noticed three distinct camps.
> 1) Large businesses are still using J2EE but have not moved to EJB3 etc
> because it really offers nothing to them. A general float away from
> proprietary frameworks (BEA) and such.
> 2) Medium businesses are using various open source frameworks.
> Spring/iBatis/etc.
> 3) Smaller businesses are using specific technologies such as Eclipse
> SWT/RCP, flash for a full website, and also need people for custom (old)
> technologies like windows sockets programming and such.
>
>    I think most of us are looking for a better stack. The traditional J2EE
> process is not highly productive. Though alot better than the alternatives
> I've seen so far. The benefit of web programming is it is very flexible and
> incremental. The handful of large companies I've consulted for simply pick a
> large J2EE vendor and throw the team into it. The problem with FOSS stacks
> is there are so many. Call it 1000 blooming flowers but it really looks like
> engineers plagued by NIH (not invented here) syndrome. Alot of the Apache
> projects simply re-invent the wheel rather than "Build on the Work of
> Others" (old Unix design guideline). Sun is at least as bad about this.
> Consider Java logging for instance. When everyone already was using and
> already does use Apache logging. NIH leads to re-evolution through the same
> painful experiences everyone experienced before with the predecessors. E.g.
> how many darn data controls do we have to have before someone decides to
> actually re-use a technology!!!!!! At least with OpenSource one certainly
> COULD reuse the technology.
>
>   IMO even if you have the most productive framework in the world there are
> so many frameworks that yours may be lost in the mix. Add in the monopoly
> marketing engine plus the cost of labor overseas and things appear
> differently. E.g. not too many people in Burundi know about Velocity and DWR
> but AJAX (at least MSXMLHTTP and client-server interaction via
> applets/ActiveX) is around a decade old and J2EE has been around a looong
> time. At $90 per year a company can hire a thousand programmer in Burundi
> for the cost of one expert in the USA. At least this is what managers often
> reason.
>
>   I'm being sarcastic of course. The $90/year is of course total BS because
> most of these people are subsistence farmers (aka conserver culture) and
> would require at least ten thousand dollars of infrastructure each and have
> no programming experience. And I totally believe the best tools lead to
> quality products and the best ROI. IMO, most of the stacks focus on
> re-invention and not much on computer science. Most people in the industry
> are well-educated and fairly cognizant of what is being done.
>
>    What is weird/sad/funny to me is the invention of new programming
> languages. Frustrating because the programming language has never been the
> limiting factor in any project I've done in my career. GUI builders,
> protocol libraries, format converters, integration support, and such are
> always missing from a new language. I guess I'm talking about Python, Ruby,
> PHP, and such. Even ANT and other psuedo-programming frameworks. I mean,
> very complex builds were being done with shell for many decades. So what if
> Windows didn't have a decent shell? Get an addon. I really believe the NIH
> problem is a severe drag on our industry and makes us look unprofessional. I
> mean, how many many hours were wasted studying XSLT and that is something
> I've never seen used in all of its "glory". One reason I quit the Microsoft
> world was the total adware frameworks they came out with every few years.
> About the time you'd integrate these into your application they'd yank the
> rug and move on to promoting something else. I try to stick to mainstream
> technologies because who even knows how to implement OLE, behaviors, or that
> distributed GUI framework thing Gates promoted in the mid-1990s? At least
> with mainstream the customer has a chance of getting a few decades from
> their investment. The framework proliferation is leading to something like
> spaghetti code. Or call it a ball of wax/mud for the industry as a whole.
>
>    In the end, none of the frameworks actually solve the customer's problem.
> It takes custom programming for most large projects. The language and the
> framework are just choices of how to skin the cat.
>
>  My $.02,
> TimJowers
>
>
>
> On 6/27/07, Shawn Hartsock <[email protected]> wrote:
> >
> > I'm currently working on a new development project and I'm curious to know
> how unique or working environment is to this group.
> >
> > Our application is on the JBoss Application Server version 4.0.5 with
> their implementation of EJB3. I've gotten EJB3 soap services and persistence
> running with the Liferay 4.2 portal in the same server instance.
> >
> > All our business logic is exposed as SOAP services to be used by our
> Portlets (or other applications). We write our portlet views in Velocity. We
> do our server-side Ajax calls in DWR 2.0 (the AOP version). We also do our
> business processes in jBPM.
> >
> > So how unique is this configuration in the triangle? In the world?
> >
> > --
> > --Shawn Hartsock
> > _______________________________________________
> > Juglist mailing list
> > [email protected]
> > http://trijug.org/mailman/listinfo/juglist_trijug.org
> >
> >
>
>


-- 
--Shawn Hartsock