From pattonm@dm.org Thu Apr 1 20:46:28 2004 From: pattonm@dm.org (Matthew Patton) Date: Thu, 1 Apr 2004 15:46:28 -0500 (EST) Subject: [Calendula-devel] Architecture Thoughts: J2EE vs Python Message-ID: 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 ======================== Python ====== 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 authentication - 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. J2EE ==== 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, anyway) - 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 frameworks) - Servlet approach better than the one-time executing scripts - 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: 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 - 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 credibility Costs of J2EE: -------------- - Language issues: - Not open source at the moment - Can be verbose - Problems arise when trying to make different versions of Java co-exist - 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, etc.) - Don't need to use ALL of their technologies, just the ones we need - 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?) 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. Thanks, Matt [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 From tpanzarella@mac.com Thu Apr 1 22:41:37 2004 From: tpanzarella@mac.com (Tom Panzarella) Date: Thu, 01 Apr 2004 17:41:37 -0500 Subject: [Calendula-devel] Architecture Thoughts: J2EE vs Python Message-ID: <5204302.1080859297732.JavaMail.tpanzarella@mac.com> 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? From tpanzarella@mac.com Thu Apr 1 22:41:43 2004 From: tpanzarella@mac.com (Tom Panzarella) Date: Thu, 01 Apr 2004 17:41:43 -0500 Subject: [Calendula-devel] Architecture Thoughts: J2EE vs Python Message-ID: <12600736.1080859303026.JavaMail.tpanzarella@mac.com> 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? From tpanzarella@mac.com Thu Apr 1 22:42:32 2004 From: tpanzarella@mac.com (Tom Panzarella) Date: Thu, 01 Apr 2004 17:42:32 -0500 Subject: [Calendula-devel] Architecture Thoughts: J2EE vs Python Message-ID: <3405862.1080859352673.JavaMail.tpanzarella@mac.com> 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? From tpanzarella@mac.com Thu Apr 1 22:46:03 2004 From: tpanzarella@mac.com (Tom Panzarella) Date: Thu, 01 Apr 2004 17:46:03 -0500 Subject: [Calendula-devel] sorry for the spam Message-ID: <10332198.1080859563575.JavaMail.tpanzarella@mac.com> sorry for the multiple copies of my last email .. this silly .mac web interface behaves really wierd sometimes ???? sorry. t. From darrylc@fudosys.com Thu Apr 1 23:28:48 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: 01 Apr 2004 15:28:48 -0800 Subject: [Calendula-devel] Architecture Thoughts: J2EE vs Python In-Reply-To: <12600736.1080859303026.JavaMail.tpanzarella@mac.com> References: <12600736.1080859303026.JavaMail.tpanzarella@mac.com> Message-ID: <1080862127.1458.65.camel@pc177.vash.kcls.org> 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!" From tpanzarella@mac.com Fri Apr 2 00:44:29 2004 From: tpanzarella@mac.com (Tom Panzarella) Date: Thu, 01 Apr 2004 19:44:29 -0500 Subject: [Calendula-devel] Architecture Thoughts: J2EE vs Python Message-ID: <999158.1080866669080.JavaMail.tpanzarella@mac.com> > >The reason why I quote it is that I don't want the framework to get >overly complex. > The point of frameworks is to keep code maintainable and simple. Whether you subscribe to an exsiting framework or build your own, once the project is large enough, ultimately you are going to use one. Zope is a framework upon which other frameworks are built until ultimately one of them is the really easy way to do task X. CMF on top of Zope and Plone on top of that == "really easy web site CMS system". The same applies in Java: Struts takes the Servlet/JSP framework to another level of simplicity and managability, RMI makes it easy to invoke methods on remote objects, other J2EE based frameworks do the same thing for other facets of distributing computing. > >Three red flags keep me out of the java camp: > >1. My own lack of java experience > Very valid reasoning. > >2. I am a perl -> python convert because of the uncluttered nature of >python. Java is a little noisy. > I'll be the first to admit that Java is a bit verbose but I don't think anyone can argue that it is not "clean". Also, Java's verbosity is due to the fact that it is a statically typed compiled language. You have to dot your "i's" and cross your "t's". > >2. Java licensing. > How would Java licensing affect Calendula? The licensing of Java effects people like IBM, BEA, Oracle and the like. As far as "we" are concerned it's free beer and we can give away our code under whatever licensing scheme we would like, even the GPL. Think of Java as an operating system and Calendula as the application that rides on top it -- I doubt the Python version of Calendula will need to make kernel modifications to windows or Linux, right? So who cares that we can't change the public interface of and redistribute the Java platform??? > >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, > I just want to clear up one thing and this is not targeted at Darryl but rather "the industry" in general. The word "enterprise" is so over used and it's essentailly marketing-ese for "distributed computing" - multiple programs interacting with eachother over a network. I'm assuming a full multi-user install of Calendula will be able to be marketed as: "enterprise python code" or some other buzz word friendly way to drive downloads. > > 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. > Very smart man. I vote Python! Also, I think you are doing a great job Darryl and I'm doing exactly what I said I wouldn't do up front ... I'm involved in defending Java on an otherwise Python slanted list when really what this is about is results for NGOs not the technical merits of languages, platforms, frameworks, etc. 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. t. From bill-bell@bill-bell.hamilton.on.ca Fri Apr 2 00:57:01 2004 From: bill-bell@bill-bell.hamilton.on.ca (Bill Bell) Date: Thu, 01 Apr 2004 19:57:01 -0500 Subject: [Calendula-devel] Architecture Thoughts: J2EE vs Python In-Reply-To: <5204302.1080859297732.JavaMail.tpanzarella@mac.com> Message-ID: <406C740D.17317.336F1913@localhost> On 1 Apr 2004 at 17:41, Tom Panzarella wrote: > Yes, J2EE is a more robust framework for building distributed object > oriented applications than anything Python has to offer. Wouldn't be a bit surprised, given what I've seen and experienced in the Python world. > I'm not trying to diss 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 ... I've probably said this before. However, if I'm going to remain as a member of this team you'd all better get used to repetition. ;o) To me this debate is partly about whether we should use a woolly mammoth to crack a walnut. It seems to me that there are numerous issues to explore, and that we should do that work in the simplest possible setting. Which is probably neither Zope nor J2EE. > One thing that Java/J2EE lends itself to ... is the effective use of > design patterns and a community willing to share and document them in a > standard format. Since this is, to some extent and unfortunately, about Java/J2EE vs Python, I really need to mention that much of the discussion on the "main" Python list has often been couched in terms of design patterns, admittedly without including some of the patterns supported by J2EE. Patterns can be economically and readably expressed in Python code, as Tom might very well agree. (Standard doc formats?: Oh, well, one can't have everything.) > .. if you are just entering the J2EE world, it's not something you are > going to just pick up. Likewise, Zope. There would be lots of preparatory work ahead for some of us, either way. > ... the first real hurdle I see developers who come from scripting > environments have to get over is the fact that they actually have to > compile their code, run unit tests ... I daresay that a good few developers that use compiled languages are really just "scripting". AFAIK this issue has nothing much to do with whether the project chooses Python or J2EE or Java. It has to do with the project team's expectations. We all know that Python now comes with unit testing "out of the box", right? Why not simply stipulate that--no matter the architecture or language--we'll all follow that discipline--among others. (And, incidentally, as a Python bigot, I should probably not mention that the Python module was adapted from Beck's for Java.) Bill From pattonm@dm.org Fri Apr 2 21:05:44 2004 From: pattonm@dm.org (Matthew Patton) Date: Fri, 2 Apr 2004 16:05:44 -0500 (EST) Subject: [Calendula-devel] Architecture Thoughts: J2EE vs Python In-Reply-To: <999158.1080866669080.JavaMail.tpanzarella@mac.com> References: <999158.1080866669080.JavaMail.tpanzarella@mac.com> Message-ID: Thank you for your excellent insights, Tom. It is good to hear from someone who has real experience with J2EE. Your pointers and clarifications were a big help. I think one of the things that was most helpful was your clarification about the debate itself: we are not debating whether Java is better than Python, but rather we are trying to figure out which tool would be best for the job at hand. Bill has stated his preference: > To me this debate is partly about whether we should use a woolly mammoth > to crack a walnut. It seems to me that there are numerous issues to > explore, and that we should do that work in the simplest possible > setting. > > Which is probably neither Zope nor J2EE. And yet, I think that I agree more with what you were saying, Tom: > The point of frameworks is to keep code maintainable and simple. > Whether you subscribe to an exsiting framework or build your own, once > the project is large enough, ultimately you are going to use one...The > same applies in Java: Struts takes the Servlet/JSP framework to another > level of simplicity and managability, RMI makes it easy to invoke > methods on remote objects, other J2EE based frameworks do the same thing > for other facets of distributing computing. I have experience writing small-medium sized applications without frameworks or with very simple frameworks, and there are several problems that develop as the project grows: 1. It eventually becomes a maintenance nightmare because so many low-level tasks are being done explicitly every time (SQL calls, passing data from page to page, data conversions, transactions, etc.) 2. Because every chunk of code has its own arcane nuances, it is a ton of work to extend the program to do new things, and it would be a huge task to write a module for it. My point is that if Calendula is going to escape getting bloated when it reaches a certain size, you will need good tools. Furthermore, it seems that J2EE, although it has a certain amount of work tied to it up front in order to learn it, nevertheless it promises to keep things much simpler and more maintainable because the code that we write lacks all of the low-level baggage it would carry if it was written without the tools. Thus I do not think J2EE is like using a Woolly Mammoth to crack a walnut (that is, unless you do not plan to have Calendula grow very big). Rather, it is a tool to help us write clean, well-organized, long-lasting code that we can really build on instead of nasty spaghetti code that we're constantly fighting against and re-writing. And yet, what you say below intrigues me, Tom: > Very smart man. I vote Python! > > ...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! Matt From tpanzarella@mac.com Sat Apr 3 21:26:41 2004 From: tpanzarella@mac.com (Tom Panzarella) Date: Sat, 03 Apr 2004 16:26:41 -0500 Subject: [Calendula-devel] Architecture Thoughts: J2EE vs Python Message-ID: <2985822.1081027601440.JavaMail.tpanzarella@mac.com> >> ...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. From tpanzarella@mac.com Sat Apr 3 21:27:40 2004 From: tpanzarella@mac.com (Tom Panzarella) Date: Sat, 03 Apr 2004 16:27:40 -0500 Subject: [Calendula-devel] Architecture Thoughts: J2EE vs Python Message-ID: <7610568.1081027660409.JavaMail.tpanzarella@mac.com> >> ...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. From maasj@dm.org Sun Apr 4 03:23:53 2004 From: maasj@dm.org (Jason Maas) Date: Sat, 3 Apr 2004 21:23:53 -0500 (EST) Subject: [Calendula-devel] Architecture Thoughts: J2EE vs Python In-Reply-To: <2985822.1081027601440.JavaMail.tpanzarella@mac.com> References: <2985822.1081027601440.JavaMail.tpanzarella@mac.com> Message-ID: Hi Tom, Thanks for sharing your real-world J2EE experience with us, it's quite helpful! On Sat, 3 Apr 2004, Tom Panzarella wrote: >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. Well said. =) >"Those who do not understand UNIX are condemned to reinvent it, poorly." I have that quote memorized and it's been funny (& sad) to watch M$ stumble their way down the path to a poor man's unix. =) But anyway, let's get back to the point at hand... >Could we port that over to J2EE? I'm not sure I understand your point here. Are you saying here that by predominantly using Python the Calendula project is destined to poorly reinvent J2EE? Also, I didn't totally understand your response to Matt's question (paraphrased): "if you think J2EE is the best way to go, why are you so gung-ho about Python?" Are you saying that it's because you enjoy the challenge of "doing it all yourself"? Or is it because J2EE is what you do "at work" and Python is what you do "for fun"? I'm a bit confused. -Jason From tpanzarella@mac.com Sun Apr 4 04:42:07 2004 From: tpanzarella@mac.com (Tom Panzarella) Date: Sat, 03 Apr 2004 22:42:07 -0500 Subject: Fwd: Re: [Calendula-devel] Architecture Thoughts: J2EE vs Python Message-ID: <12295491.1081050127052.JavaMail.tpanzarella@mac.com> From: Tom Panzarella TO: Jason Maas CC: Date: Sat Apr 03, 2004 10:40:33 PM EST Subject: Re: [Calendula-devel] Architecture Thoughts: J2EE vs Python > >let's get back to the point at hand... > >>Could we port that over to J2EE? > >I'm not sure I understand your point here. Are you saying here that by >predominantly using Python the Calendula project is destined to poorly >reinvent J2EE? > No. What I am saying is that J2EE has already addressed many of the issue that Calendula will have to face. Starting from "scratch" is hard. J2EE is nothing but a set of API specifications that addresses all of the "known" issues that are common to distributed apps. The implementors of the J2EE spec (be it BEA, IBM, or JBoss) have already built the plumbing necessary for application developers to focus on their application specific needs. I don't know of anything in the Python world that is nearly as comprehensive or robust to even compare ... So.... if the implementation of Calendula is in Python, many of the same concerns already addressed by J2EE will have to be considered by the Calendula developers. > >Also, I didn't totally understand your response to Matt's question >(paraphrased): "if you think J2EE is the best way to go, why are you >so gung-ho about Python?" > Because the project manager, Darryl, has declared it his choice. He is very smart in doing this. He is comfortable with Python and it's capabilities. If everyone else were to "quit" tomorrow, he would still have a workable code base in his lap. There is much more to picking a platform and architecture than pure technical merits ... one must take a pragmatic view when heading up a project such as Calendula. > >Are you saying that it's because you enjoy the >challenge of "doing it all yourself"? > No, but it can be fun -- but I'm not interested in Calendula to "reinvent the wheel", I am attracted to this project because it will help NGOs ... a business sector that I hold very close to my heart. > >Or is it because J2EE is what >you do "at work" > Partially ... although, even though I work primarily in a J2EE environment, I still love Java programming -- the innovation in the Java community is unrivaled compared to what I have seen elsewhere ... again, just an opinion. > >and Python is what you do "for fun"? I'm a bit confused. > Good question. I actually haven't done anything in Python that I would consider *real* in a very long time. I use Python (and Perl and /bin/bash ... depending on my mood) to do the little "hacks" that I need on a day-to-day basis -- because that is what I am good at using those languages for. Currently, what I am doing for "fun" is Groovy (http://groovy.codehaus.org/) programming. t. From pattonm@dm.org Tue Apr 27 15:40:20 2004 From: pattonm@dm.org (Matthew Patton) Date: Tue, 27 Apr 2004 10:40:20 -0400 (EDT) Subject: [Calendula-devel] Final decision Message-ID: Hi Darryl et al, Just wanted to let you all know of the decision of us four here at DiscpleMakers to go ahead with J2EE development of a suite of software for non-profits. The project URL is: http://daniel.sf.net/ Since J2EE provides all of the low-level architecture solutions we need (instead of us having to reinvent them in Python), we felt it was the best way to go. We're sorry it didn't work out to partner with all of you since we share very similar visions, and we appreciate the stimulating discussions we've had with you all. Thanks, Matt ______________________________________________________________ Matthew Patton pattonm@dm.org DiscipleMakers Headquarters: (814)234-7975 x32