[Calendula-devel] Architecture Thoughts: J2EE vs Python

[Tom Panzarella]

>> ...If I were the architect, I'd choose J2EE, but I'm not.
>> At the same time I do think that a Python system can be architected to
>> scale and work too.  Let's do it.
>>
>
>Although you personally would prefer J2EE, you seem to see Python as an
>option.  Why is that?  What architecture design patterns are you thinking
>of?  What tools are you thinking of that are already in existence for
>Python that will enable us to leap right into writing Calendula?
>	From the research I've done of the tools available for Python, I
>don't see how we can expect to write a distributed, extensible,
>multi-layered multi-user application in Python.  Unless you intend to make
>Calendula a simple, lightweight application for a specific limited purpose
>(fundraising), then I think we're going to need something like J2EE.  But
>I'd be glad to be proved wrong.  Thanks very much for your thoughts!
>

In a former position I held at a scientific computing company / software ve=
ndor, I worked in the middleware division where we (me and 10+ other softwa=
re engineers) were charged with building (not buying) an application server=
 to support our organization's entire suite of internet based applications =
which were written in disparate languages: some Java, some perl, some C++ c=
gi's (no joke!), etc.  We had to engineer and distill out the common set of=
 infrastrucure services all of these applications needed in order to make t=
he individual apps "thinner" -- and to enable quicker time-to-market with n=
ew products.  As we were working out the architecture for our middleware se=
rver we found that certain languages were better for a particular job than =
others.  So we decided to build out our app server in a very modular fashio=
n where each core component "spoke" to another component via a "web service=
s" type architecture -- we didn't use any "standard" protocol like SOAP bec=
ause it was too "chatty" to handle the immense amount of remote calls we wo=
uld have to send over the wire, but the point is, we worked out our own wir=
e-level protocol that was encoded in a language independent manner to enabl=
e reasonable RPC/RMI type communication between our server components.  The=
 result was that some folks implemented their piece in Java, others did it =
in mod_perl, and others in C. Our "public interfaces" were very clean so, w=
e had all this stuff talking to eachother and it was great.  We didn't real=
ly care about "portability" because we weren't selling the middleware to an=
yone (the apps were sold on a subscription basis in an ASP type of environm=
ent) and we knew our deployment environment intimately (Solaris 8 across bo=
ard).  It was fun to build from an engineering perspective and it really pr=
oved to be finanically rewarding for the company.=20=20

That was version 1.  As additional requirements kept rolling in for new app=
s to ride on top of our server, refactorings to existing apps, low-level pe=
rformance issues, more stringent security concerns, etc. we began to get "o=
verloaded" since we had to build all of this stuff in ourselves.  Again, fr=
om an engineering perspective it was great fun, but we also had the dreaded=
 deadlines and we simply couldn't keep pace with building, testing, and rel=
easing our code to satisfy our marketing and sales department -- they were =
selling features to clients that hadn't even made it to our desks as a requ=
irement yet (probably not all that uncommon).  Anyway, we kept supporting o=
ur server as "dot" releases to the 1.x tree but we ultimately chose to push=
 back on the application developers to port their code over to Java so we c=
ould implement the 2.x tree using J2EE so we could focus on our specific bu=
siness needs and not the plumbing.

Ultimately I moved on from that company but I periodically check out the li=
ve environments where the applications live to see how the middleware is ho=
lding up (since I'm a former engineer with them, I know ways to determine w=
hat is running what ;-)  I proud to say they still haven't deployed the J2E=
E version yet which means some variation of our 1.x code is still running o=
ut there.

My point is that it is possible to build well designed modular code to work=
 in a distributed environement that is not J2EE or .Net and be successful. =
 But when you do, you are opened up a whole new set of challenges -- not on=
ly do you have to build the business specific logic but you will mostly spe=
nd your time writing "plumbing" or infrastructure code (i.e. building *your=
* framework) -- persistence mechanisms, database connection pools and query=
 brokers, auth* subsystems, communications protocols, etc etc etc.

This type of thing reminds me of a quote from Henry Spencer (http://www.lys=
ator.liu.se/c/henry/) about the UNIX operating system, he says:

"Those who do not understand UNIX are condemned to reinvent it, poorly."

Could we port that over to J2EE?

t.