[Calendula-devel] Architecture Thoughts: J2EE vs Python

[Tom Panzarella]

There is a lot of information here but I think it warrants more input.  I h=
ave to confess up front that some of what I say may be biased due to the fa=
ct that I am primarily a Java/J2EE developer although I have reasonable exp=
erience with Python -- I just really like Java.  In general I agree with wh=
at Matt is saying but I think there are more things to consider.=20=20

Yes, J2EE is a more robust framework for building distributed object orient=
ed applications than anything Python has to offer.  I'm not trying to diss =
Python at all, I just prefer to use a hammer to bang in a nail and a fork t=
o eat my food unless it is soup in which case I prefer a spoon.  If that an=
alogy makes any sense, what I'm saying is Java/J2EE IS a better choice for =
large (define as you wish) distributed business applications than Python. A=
nd Python is a better choice than Java for   things like mailing list manag=
ers (ala Mailman).

I still want to stress that I think that architecture is much more importan=
t than implementation language/platform.  I've seen some real "train wreck"=
 J2EE apps which I think are partially due to the fact that the developers =
don't fully understand what they are doing.  One thing that Java/J2EE lends=
 itself to (beyond all of the acronyms ... more on that later) is the effec=
tive use of design patterns and a community willing to share and document t=
hem in a standard format.  For example, a popular thing today in the J2EE c=
ommunity is to NOT use CMP and EJB but rather use ORM tools and frameworks =
(i.e. Hibernate, OJB, TopLink, etc.) to implement a persistence tier for sa=
ving the state of POJOs (Plain old java objects) within distributed apps.  =
Best practices and patterns that have developed around EJB to allow for net=
work transparency and such have also been modified to support these other a=
lternative frameworks.  Getting specific now is way beyond the scope of thi=
s email.

The major issue for this project I think is two-fold: 1) skills 2) the proj=
ect leader already declared Python.  On the first point, if you are just en=
tering the J2EE world, it's not something you are going to just pick up.  I=
f you are already a Java programmer and have some experience with design pa=
tterns you have a better shot of breaking down the barriers to entry.  I'm =
not saying that the developers on this list can't do it, I'm just saying th=
at it will take some time to learn all the appropriate pieces and how they =
interact with eachother -- there is a lot of crap to learn.  Honestly, the =
first real hurdle I see developers who come from scripting environments hav=
e to get over is the fact that they actually have to compile their code, ru=
n unit tests (well you should at least), and then deploy -- it's not just e=
dit the code, "C-x C-s", then hit "refresh" on your browser.

I've made some particular comments in-line with Matt's email below .....
=20
>
>	It was mentioned by several of you a while back when there was a
>debate about which language to use that the more important thing than the
>specific language is the particular *architecture* we use for our program:
>
>Thomas Panzarella: "Also, I think much more important that the ultimate
>language is the architecture."
>

Nice comment, who's that guy ;-)

>
>Bill Bell: "Perhaps we can agree that we will surely fail if we do a poor
>job of the architecture."
>

Agreed.

>
>	I didn't hear much back from you all on this, and we have actually
>since been reconsidering our plans for developing these tools for Python.
>The reconsideration comes from looking at J2EE [1], which is a free ("as
>in beer", not OSS) set of tools for Java for developing just the sort of
>app that Calendula is to be.=20=20
>

A quick word on this.  Java is not OSS as defined by OSI (http://www.openso=
urce.org) but you can access the source to the the Java platform via the Su=
n Community Source License which let's you do whatever you want except for =
fork the platform.  Then of course if you do build your own Java implementa=
tion (for some odd reason) you will certainly have to pay license fees to S=
un to get certified as pure Java.  As for J2EE, Tomcat (http://jakarta.apac=
he.org) is already the reference implementation for the Servlet/JSP/JSF pie=
ce of J2EE (so the source is readily available for that) and just recently =
Sun granted Apache a "scholorship" to build Geronimo (an EJB container) whi=
ch will be allowed to receive J2EE certification (something that JBoss does=
 not have -- totally different conversation there).  It should also be note=
d that most of the "stuff" that Java/J2EE developers use on a daily basis a=
ll comes from the OSS community and Java itself has a very vibrant OSS comm=
unity rallying around it.  I can go on for days on this (especially since I=
 ran a discussion at Penguin Day on this exact topic) but I will spare ever=
yone the details.

For the curious, you can get the full source to the J2SE here:

http://wwws.sun.com/software/communitysource/j2se/java2//download.html


>
>J2EE vs. Python Decision
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>Python
>=3D=3D=3D=3D=3D=3D
>
>Benefits of Python:
>-------------------
>
>- Language is preferrable in some ways to Java:
>	- Elegant and readable

This is not fact but rather one opinion.  Here is a funny interpretation of=
 someone who thinks just the opposite:

Full text of this blog entry can be found here:
http://www.theserverside.com/blogs/showblog.tss?id=3DGroovyReview

--- start of quote ---

Put in the simplest terms, it [Python] feels like a very annoying language =
to me. Writing 'lambda' all of the place seems the height of silliness. The=
y can keep their 'self'. Double underscores get real old real fast - even i=
n just a few hours. "def"? "DEF"? WTF? I don't think I can use a language t=
hat defines methods with a keyword "DEF" (aside: And I'm pissed that Groovy=
 requires DEF, but at least its only in one specific case).

--- end of quote ---

>
>Summary: Python as a language is superior to Java in many ways,=20
>

I'd change that line to: "Python as a language is better suited to certain =
tasks than Java."

>
>
>J2EE
>=3D=3D=3D=3D
>
>Benefits of J2EE:
>-----------------
>
>- Complete, mature toolset already in place
>	- JBoss is an OSS alternative to Sun's J2EE implementation

True, but at this point I'd only suggest using JBoss if you want to use EJB=
 which is not necessary and sometimes undesirable in J2EE apps.  EJB has a =
lot of overhead to it that the marketing folk don't like to mention.  But t=
hen again that is why there is JDO and other object relational persistance =
frameworks out there.

>
>- J2EE toolset implements many things that Python lacks:
>	- Excellent client frameworks (both with Struts and the J2EE
>	frameworks)
>

I will echo the praises of Struts.  (Twinkle Twinkle -- inside joke for tho=
se who made it to Penguine Day ;-)

>
>		- Servlet approach better than the one-time executing
>		scripts
>

Yep. And it's multithreaded nature make it *better* than things like FastCG=
I or mod_perl as well.

... aside: Sorry Perl people I mean no harm, I am a big Perl / mod_perl fan=
 as well

>
>		- Model-View-Controller concepts in both Struts and J2EE
>

True.  But MVC will only be one pattern necessary for an overall sound arch=
itecture.

>
>	- Enterprise Java Beans (EJB) are extremely powerful
>

True but not the only option.

>
>		- (MOST IMPORTANT) Allows encapsulation of how data is
>		stored and the complexities of the business logic (hides
>		this from client) through a remotely accessible API
>

You don't need EJB for that .. you just need to write clean interfaces and =
apply the appropriate patterns.  I think what EJB is good at is all of the =
"stuff" the container gives you:

CMP - Container managed persistence for entity beans will keep your databas=
e and distributed components' state in synch without a single line of SQL w=
ritten by you.

Network transparency - "clients" of EJBs don't have to know where the heck =
they are.  You look them up in a registry (JNDI) and then call methods on t=
he bean's public interface.

There is more: security, transactions, etc.

>
>		- Very nice and flexible object-relational layer (with
>		Hibernate as another excellent OSS possibility)
>

Yep.  You can use Hibernate outside of EJB as well.  Also check out OJB:

http://db.apache.org/ojb/

>
>		- Allows transactions of large operations that can be
>		rolled back (larger in scope than just DB transactions)
>		- Provides means for handling data security
>		- Helpful links to learn the basics:
>		http://www.javaworld.com/javaworld/jw-10-1998/jw-10-beans.html
>		(Beginner's overview)
>		http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html
>		(Tutorial for J2EE, check out Chapter 27: Method
>		Invocations in RosterApp for code examples)
>
>	- Distributed objects via excellent communication systems
>		- Java Remote Method Invocation (RMI) allows remote access
>		of EJB's and transmission of complex data types and
>		exceptions
>

You can use RMI in standalone mode as well if you choose not to use EJB but=
 still want to make calls on remote objects or send serialized objects acro=
ss the wire between virutal machines.

>
>		- Asynchronous messaging between objects
>
>	- Managing and deploying web services
>
>	- Provides all the robustness of a high-quality server:
>	scalability, reliability (failover), extensibility,
>	load balancing, component hotswapping, security
>
>- Java a widely used language
>	- Lots of other OSS tools available (Ant, Struts, etc.)
>

Lots lots lots.  Ant is a key peice of technology for managing the build an=
d deployment of Java projects. The other real staples I'd say are JUnit and=
 XDoclet (especially if you are doing EJB).  Middlegen is also very useful.

>
>	- Many resources for developers
>	- Large development community: broad industry support and
>	credibility
>

One other "biggie" for Java that I'd throw in is built in support for easil=
y building Internationalized applications.  Struts also builds on Java's al=
ready excellent ResourceBundle framework.

>
>Costs of J2EE:
>--------------
>
>- Language issues:
>	- Not open source at the moment
>	- Can be verbose
>

True but it's getting better.  "Tiger" (J2SE 1.5.0) will have autoboxing an=
d unboxing of variables so that will cut down on the amount of explicit typ=
e casts that clutter up Java code.  And if you can follow it, many of the A=
PIs have been designed in such a way to promote method invocation chaining =
which also tends to save a few key strokes here and there.  I guess this is=
 one of the things that Groovy (http://groovy.codehaus.org/) is addressing.

>
>	- Problems arise when trying to make different versions of Java
>	co-exist
>

unlike inconsistences in C libraries on UNIX systems?  Or "dll hell" on Win=
dows? I don't think you can fault Java for this ... this is pretty much acr=
oss the board in computing -- regardless of claims for "backward compatibil=
ity".

>
>	- Clunkiness of UI's (perhaps attenuated by wxWidgets?)
>

Matter of opinion.  I tend to like Swing.  But perhaps you'd prefer SWT:

http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html

>
>- Learning curve: too complex for our needs?
>	- Attenuated by the fact that not everyone needs to know the
>	entire J2EE spec, just the parts that pertain to them (JSP, EJB,
>	etc.)
>

It's a constant learning process.  Certainly not going to happen overnight =
but it's doable.


>
>	- Don't need to use ALL of their technologies, just the ones we
>	need
>

This cannot be stressed enough.  Don't make it more overwhelming than it al=
ready is.

>
>	- It takes a while to wade through the docs and all of the
>	acronyms, but it begins to make sense eventually.  At least it
>	lacks a lot of the complex and arcane wierdness that an immature
>	system inevitably has.
>

As far as the acronyms go, they are all marketing.  They simply give a name=
 to a piece of the functionality the API has to offer.  Focus on concepts a=
nd not acronyms.

>
>- With JBoss we would have to pay for docs beyond the tutorial (may not be
>necessary for our purposes)
>

If you aren't going to use EJB, I'd say don't use JBoss.  There has been a =
bit of skeptism as of late about their fearless leader (I am not going to n=
ame names here).  I think the community will adapt Geronimo as the defacto =
open source certified J2EE container once it gets built -- this statement i=
s based on Apache's already proven track record.

Technically, JBoss is great.  You can also check out Resin as well which im=
plements thier own version of doing CMP -- not J2EE certified but still pre=
tty nice.

You can check out Resin here: http://www.caucho.com/

>
>Summary: J2EE is an excellent toolset that has basically everything we
>need and much more, although the Java language itself has some (minor?)
>issues.
>
>-------------------------------------
>
>That's what I have gathered from our research and your input.  What
>motivates us in all of this is the conviction that excellent business
>software needs to be written in a layered, distributed, n-tier approach
>with the layers clearly delineated and abstracted, and so we are seeking
>the best tools that will enable us to do this.  Please correct me on any
>areas where you think what I have said is incorrect, or if you think there
>is anything I'm overlooking.
>	I recognize that since you are a GNU project there may be
>restrictions to using a non-Free language like Java.  Java is:
>"Free for development, production deployment, and redistribution" [6]
>but it is NOT Open Source.  There are attempts to reproduce Java as Open
>Source, but as I understand it these are only at the point of Java Virtual
>Machine (JVM) 1.2, and not at 1.4, which is what JBoss requires.
>	At this point, I'd say we (here at DM) are getting close to making
>a decision as to which direction to pursue, and are leaning towards the
>J2EE option, but we would welcome comments from you all.
>

Where is your project page again?