[Calendula-devel] Architecture Thoughts: J2EE vs Python

[Darryl Caldwell]

Howdy,

I found this quote on a python archive the other day:

"I've written a 24,000 line Python program that's a patient=20
database/accounting program for an optometric/optician office. It uses
PostgreSQL as the database to store all the data. Since most of the
data processing is done by SQL commands it is plenty fast. It contains
over 10,000 patients and 16,000 transactions right now. Doing many of
the data tabulations would most likely be too slow if all the code
were written in Python. And of course using a real database allows
committing/rolling back a number of SQL statements at once and the big
one for this application is allowing multiple users.

I used PyGtk - used Glade to design each window. There are separate
window for entering patient info, frames, professional fees,
frame/lens purchase with Rx, reconciling insurance payments, tracking
the cash register contents and bank deposits, etc. 41 windows in total
I think."

http://mail.python.org/pipermail/python-list/2004-March/210174.html

I've email the developer and he said this was just a summer project to
keep him busy....

The reason why I quote it is that I don't want the framework to get
overly complex.=20

Three red flags keep me out of the java camp:

1. My own lack of java experience

2. I am a perl -> python convert because of the uncluttered nature of
python. Java is a little noisy.

2. Java licensing.

Calendula is a side project for me at this point, but it is also a
necessary one because of my commitment to the NPO sector. To date, I
haven't heard of another project with the same market in mind.

It may only be a stepping stone to a more full bodied effort backed by
the resources to make it happen. So unless someone comes up with some
really compelling reasons to jump to enterprise level code, the guiding
principle for me will be to keep it simple. Or as I like to say now, if
you all disappear I've got to be able to do it myself.

-D



On Thu, 2004-04-01 at 14:41, Tom Panzarella wrote:
> There is a lot of information here but I think it warrants more input.  I=
 have to confess up front that some of what I say may be biased due to the =
fact that I am primarily a Java/J2EE developer although I have reasonable e=
xperience with Python -- I just really like Java.  In general I agree with =
what 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 orie=
nted applications than anything Python has to offer.  I'm not trying to dis=
s Python at all, I just prefer to use a hammer to bang in a nail and a fork=
 to eat my food unless it is soup in which case I prefer a spoon.  If that =
analogy makes any sense, what I'm saying is Java/J2EE IS a better choice fo=
r large (define as you wish) distributed business applications than Python.=
 And Python is a better choice than Java for   things like mailing list man=
agers (ala Mailman).
>=20
> I still want to stress that I think that architecture is much more import=
ant than implementation language/platform.  I've seen some real "train wrec=
k" J2EE apps which I think are partially due to the fact that the developer=
s don't fully understand what they are doing.  One thing that Java/J2EE len=
ds itself to (beyond all of the acronyms ... more on that later) is the eff=
ective use of design patterns and a community willing to share and document=
 them in a standard format.  For example, a popular thing today in the J2EE=
 community is to NOT use CMP and EJB but rather use ORM tools and framework=
s (i.e. Hibernate, OJB, TopLink, etc.) to implement a persistence tier for =
saving the state of POJOs (Plain old java objects) within distributed apps.=
  Best practices and patterns that have developed around EJB to allow for n=
etwork transparency and such have also been modified to support these other=
 alternative frameworks.  Getting specific now is way beyond the scope of t=
his email.
>=20
> The major issue for this project I think is two-fold: 1) skills 2) the pr=
oject leader already declared Python.  On the first point, if you are just =
entering the J2EE world, it's not something you are going to just pick up. =
 If you are already a Java programmer and have some experience with design =
patterns 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 =
that it will take some time to learn all the appropriate pieces and how the=
y interact with eachother -- there is a lot of crap to learn.  Honestly, th=
e first real hurdle I see developers who come from scripting environments h=
ave to get over is the fact that they actually have to compile their code, =
run unit tests (well you should at least), and then deploy -- it's not just=
 edit the code, "C-x C-s", then hit "refresh" on your browser.
>=20
> 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 th=
e
> >specific language is the particular *architecture* we use for our progra=
m:
> >
> >Thomas Panzarella: "Also, I think much more important that the ultimate
> >language is the architecture."
> >
>=20
> Nice comment, who's that guy ;-)
>=20
> >
> >Bill Bell: "Perhaps we can agree that we will surely fail if we do a poo=
r
> >job of the architecture."
> >
>=20
> Agreed.
>=20
> >
> >	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.open=
source.org) but you can access the source to the the Java platform via the =
Sun Community Source License which let's you do whatever you want except fo=
r fork the platform.  Then of course if you do build your own Java implemen=
tation (for some odd reason) you will certainly have to pay license fees to=
 Sun to get certified as pure Java.  As for J2EE, Tomcat (http://jakarta.ap=
ache.org) is already the reference implementation for the Servlet/JSP/JSF p=
iece of J2EE (so the source is readily available for that) and just recentl=
y Sun granted Apache a "scholorship" to build Geronimo (an EJB container) w=
hich will be allowed to receive J2EE certification (something that JBoss do=
es not have -- totally different conversation there).  It should also be no=
ted that most of the "stuff" that Java/J2EE developers use on a daily basis=
 all comes from the OSS community and Java itself has a very vibrant OSS co=
mmunity 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 ev=
eryone the details.
>=20
> For the curious, you can get the full source to the J2SE here:
>=20
> http://wwws.sun.com/software/communitysource/j2se/java2//download.html
>=20
>=20
> >
> >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
>=20
> This is not fact but rather one opinion.  Here is a funny interpretation =
of someone who thinks just the opposite:
>=20
> Full text of this blog entry can be found here:
> http://www.theserverside.com/blogs/showblog.tss?id=3DGroovyReview
>=20
> --- start of quote ---
>=20
> Put in the simplest terms, it [Python] feels like a very annoying languag=
e to me. Writing 'lambda' all of the place seems the height of silliness. T=
hey can keep their 'self'. Double underscores get real old real fast - even=
 in just a few hours. "def"? "DEF"? WTF? I don't think I can use a language=
 that defines methods with a keyword "DEF" (aside: And I'm pissed that Groo=
vy requires DEF, but at least its only in one specific case).
>=20
> --- end of quote ---
>=20
> >
> >Summary: Python as a language is superior to Java in many ways,=20
> >
>=20
> I'd change that line to: "Python as a language is better suited to certai=
n tasks than Java."
>=20
> >
> >
> >J2EE
> >=3D=3D=3D=3D
> >
> >Benefits of J2EE:
> >-----------------
> >
> >- Complete, mature toolset already in place
> >	- JBoss is an OSS alternative to Sun's J2EE implementation
>=20
> True, but at this point I'd only suggest using JBoss if you want to use E=
JB 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=
 then again that is why there is JDO and other object relational persistanc=
e frameworks out there.
>=20
> >
> >- J2EE toolset implements many things that Python lacks:
> >	- Excellent client frameworks (both with Struts and the J2EE
> >	frameworks)
> >
>=20
> I will echo the praises of Struts.  (Twinkle Twinkle -- inside joke for t=
hose who made it to Penguine Day ;-)
>=20
> >
> >		- Servlet approach better than the one-time executing
> >		scripts
> >
>=20
> Yep. And it's multithreaded nature make it *better* than things like Fast=
CGI or mod_perl as well.
>=20
> ... aside: Sorry Perl people I mean no harm, I am a big Perl / mod_perl f=
an as well
>=20
> >
> >		- Model-View-Controller concepts in both Struts and J2EE
> >
>=20
> True.  But MVC will only be one pattern necessary for an overall sound ar=
chitecture.
>=20
> >
> >	- Enterprise Java Beans (EJB) are extremely powerful
> >
>=20
> True but not the only option.
>=20
> >
> >		- (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
> >
>=20
> You don't need EJB for that .. you just need to write clean interfaces an=
d apply the appropriate patterns.  I think what EJB is good at is all of th=
e "stuff" the container gives you:
>=20
> CMP - Container managed persistence for entity beans will keep your datab=
ase and distributed components' state in synch without a single line of SQL=
 written by you.
>=20
> Network transparency - "clients" of EJBs don't have to know where the hec=
k they are.  You look them up in a registry (JNDI) and then call methods on=
 the bean's public interface.
>=20
> There is more: security, transactions, etc.
>=20
> >
> >		- Very nice and flexible object-relational layer (with
> >		Hibernate as another excellent OSS possibility)
> >
>=20
> Yep.  You can use Hibernate outside of EJB as well.  Also check out OJB:
>=20
> http://db.apache.org/ojb/
>=20
> >
> >		- 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
> >
>=20
> You can use RMI in standalone mode as well if you choose not to use EJB b=
ut still want to make calls on remote objects or send serialized objects ac=
ross the wire between virutal machines.
>=20
> >
> >		- 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.)
> >
>=20
> Lots lots lots.  Ant is a key peice of technology for managing the build =
and deployment of Java projects. The other real staples I'd say are JUnit a=
nd XDoclet (especially if you are doing EJB).  Middlegen is also very usefu=
l.
>=20
> >
> >	- Many resources for developers
> >	- Large development community: broad industry support and
> >	credibility
> >
>=20
> One other "biggie" for Java that I'd throw in is built in support for eas=
ily building Internationalized applications.  Struts also builds on Java's =
already excellent ResourceBundle framework.
>=20
> >
> >Costs of J2EE:
> >--------------
> >
> >- Language issues:
> >	- Not open source at the moment
> >	- Can be verbose
> >
>=20
> True but it's getting better.  "Tiger" (J2SE 1.5.0) will have autoboxing =
and unboxing of variables so that will cut down on the amount of explicit t=
ype casts that clutter up Java code.  And if you can follow it, many of the=
 APIs have been designed in such a way to promote method invocation chainin=
g 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 addressin=
g.
>=20
> >
> >	- Problems arise when trying to make different versions of Java
> >	co-exist
> >
>=20
> unlike inconsistences in C libraries on UNIX systems?  Or "dll hell" on W=
indows? I don't think you can fault Java for this ... this is pretty much a=
cross the board in computing -- regardless of claims for "backward compatib=
ility".
>=20
> >
> >	- Clunkiness of UI's (perhaps attenuated by wxWidgets?)
> >
>=20
> Matter of opinion.  I tend to like Swing.  But perhaps you'd prefer SWT:
>=20
> http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html
>=20
> >
> >- 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.)
> >
>=20
> It's a constant learning process.  Certainly not going to happen overnigh=
t but it's doable.
>=20
>=20
> >
> >	- Don't need to use ALL of their technologies, just the ones we
> >	need
> >
>=20
> This cannot be stressed enough.  Don't make it more overwhelming than it =
already is.
>=20
> >
> >	- 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.
> >
>=20
> As far as the acronyms go, they are all marketing.  They simply give a na=
me to a piece of the functionality the API has to offer.  Focus on concepts=
 and not acronyms.
>=20
> >
> >- With JBoss we would have to pay for docs beyond the tutorial (may not =
be
> >necessary for our purposes)
> >
>=20
> 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=
 name names here).  I think the community will adapt Geronimo as the defact=
o open source certified J2EE container once it gets built -- this statement=
 is based on Apache's already proven track record.
>=20
> Technically, JBoss is great.  You can also check out Resin as well which =
implements thier own version of doing CMP -- not J2EE certified but still p=
retty nice.
>=20
> You can check out Resin here: http://www.caucho.com/
>=20
> >
> >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 the=
re
> >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 Virtu=
al
> >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.
> >
>=20
> Where is your project page again?
>=20
>=20
> _______________________________________________
> Calendula-devel mailing list
> Calendula-devel@fudosys.com
> http://list.fudosys.com/mailman/listinfo/calendula-devel
--=20
Darryl Caldwell darrylc@fudosys.com
Fudo Systems  www.fudosys.com
206/567-5802  "Free Your Computers!"