[Calendula-devel] Architecture Thoughts: J2EE vs Python

Matthew Patton pattonm@dm.org
Thu, 1 Apr 2004 15:46:28 -0500 (EST)

Hello everyone,
	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."
Bill Bell: "Perhaps we can agree that we will surely fail if we do a poor
job of the architecture."

There was general consensus about this, and so I posted the thoughts that
we (Tom, Jason, Brian, and I at DiscipleMakers) had been developing with
regard to an architecture solution via an Open Source Enterprise
Application Toolkit for Python. [0]
	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.  It handles all of the low-level "plumbing"
of developing a distributed application (remote objects, HTML templating,
transactions, failover, load-balancing, object messaging, etc.) and is in
a much more mature state than anything in Python at the moment.
	We know that you all have already decided to use Python, and we
don't want to start a flame war (there are many things that we like about
Python), but we wanted to share with you the direction that we are leaning
towards because we really would like to work with you to meet the software
needs of Non-Profits if at all possible.
	Below is a cost-benefit analysis for either side of the decision.
Would you consider it and let us know if we are overlooking anything?

J2EE vs. Python Decision


Benefits of Python:

- Language is preferrable in some ways to Java:
	- Elegant and readable
	- Open source
	- Rapid coding: is a scripting language, so implicit typing, no
	need to expressly compile, etc.

- Several tools that we need already exist and are viable:
	- Zope [2] for a server to serve up objects and handle
	- Modeling [3] for object-relational mapping

Costs of Python:

- Entire toolset not in place
	- Lacking:
		- Business Logic Framework
			- Would provide standards for writing business logic
			- Need to handle security, sessions, etc.
		- Advanced remote procedure calling protocol
		 	- Although there is an excellent XML-RPC library
			in existence [4], we still need to be able to pass
			objects and reference params at the bare minimum
			- A more advanced (but almost as necessary)
			feature would be allowing more than just static
			methods to be called (i.e.,a remote references to
			instances of objects on the server)
			- This remote object scheme is no joke to
			implement, and is necessary if Calendula is to be
			scalable and flexible in its design
		- Client Frameworks
			- All existing frameworks are too immature
			- We need a strong Model-View-Controller design
			like Struts [5] that elegantly handles the
			complexities of web programming (how to overcome
			http's statelessness, the back-button, etc.)
		- Ultimately, we are lacking the robustness and power and
		flexibility that comes from a unified solution like J2EE

	- Will need to implement these tools, involving:
		- Designing (including research which would probably
		involve learning lots about J2EE anyway)
		- Implementation (coding and testing)
		- Communication
			- Lots of documenting
			- SF website management
			- Mailing lists
			- Example project
		(I said before this would not take more than a few months,
		but consider this: a couple months before an *ALPHA*
		version that doesn't do more than a fraction of what J2EE
		does and that will be in considerable flux until we
		stabilize our design ideas)

	- Those tools that are already available have issues:
		- Zope: docs are hard to understand
		- Modeling: still Beta, only partial implementation of
		Apple's Enterprise Object Framework, head developer is
		very attentive but is working on it basically alone in
		his free time

Summary: Python as a language is superior to Java in many ways, but it
lacks some of the tools that we need if we are to have an excellent
architecture to build a long-lasting solution on top of.  We could write
our own tools, but they would be immature and inferior for some time, and
would require considerable effort to implement and maintain.


Benefits of J2EE:

- Complete, mature toolset already in place
	- JBoss is an OSS alternative to Sun's J2EE implementation
	- Good documentation (sometimes hard to understand, but very
	extensive, professional, and complete)
	- Design done by people who know what they're doing (more than us,
	- Good design means that we can use some tools and technologies
	and not use others that we don't want or need, thus keeping
	complexity at a minimum

- J2EE toolset implements many things that Python lacks:
	- Excellent client frameworks (both with Struts and the J2EE
		- Servlet approach better than the one-time executing
		- Model-View-Controller concepts in both Struts and J2EE

	- Enterprise Java Beans (EJB) are extremely powerful
		- (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
		- Very nice and flexible object-relational layer (with
		Hibernate as another excellent OSS possibility)
		- 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:
		(Beginner's overview)
		(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
		- 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.)
	- Many resources for developers
	- Large development community: broad industry support and

Costs of J2EE:

- Language issues:
	- Not open source at the moment
	- Can be verbose
	- Problems arise when trying to make different versions of Java
	- Clunkiness of UI's (perhaps attenuated by wxWidgets?)

- 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,
	- Don't need to use ALL of their technologies, just the ones we
	- 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.

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

Summary: J2EE is an excellent toolset that has basically everything we
need and much more, although the Java language itself has some (minor?)


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.


[0] http://list.fudosys.com/pipermail/calendula-devel/2004-March/000040.html
[1] http://java.sun.com/j2ee/
[2] http://www.zope.org
[3] http://modeling.sourceforge.net/
[4] http://www.pythonware.com/products/xmlrpc/
[5] http://jakarta.apache.org/struts/
[6] http://java.sun.com/j2ee/1.4/download.html#sdk

Matthew Patton                                  pattonm@dm.org
DiscipleMakers Headquarters: (814)234-7975 x32