doulos-devel Mailing List for Doulos Enterprise Application Toolkit
Status: Pre-Alpha
Brought to you by:
general_pattonm
Menu
▾
▴
doulos-devel — Doulos developers list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(6) |
Oct
(3) |
Nov
(3) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
(18) |
Apr
(15) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
|
From: Matthew P. <pa...@dm...> - 2004-11-02 15:38:27
|
Hi Gordon, Sorry to hear about your troubles with Doulos. Unfortunately, although the code remains available, the source is no longer being actively maintained. The answer to your question, though, can probably be found in docs/tutorial.php in your distribution directory. Matt ______________________________________________________________ Matthew Patton pa...@dm... DiscipleMakers Headquarters: (814)234-7975 x532 On Sun, 31 Oct 2004, Gordon Kerr wrote: > I just downloaded doulos-0.1.3.tar.gz and the sample isn't working - > include path mess! I'd like to know whether there is a separate library > path with the structure ctrl,model,view,misc and you build your own site > by creating a similar structure with your app's specifics. Or do you > create your model, etc. within those directories, thus the sample should > be duplicating some code which it seems not to be. > ... > Gordon > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Doulos-devel mailing list > Dou...@li... > https://lists.sourceforge.net/lists/listinfo/doulos-devel > |
|
From: Gordon K. <gk...@id...> - 2004-10-31 09:44:06
|
I just downloaded doulos-0.1.3.tar.gz and the sample isn't working - include path mess! I'd like to know whether there is a separate library path with the structure ctrl,model,view,misc and you build your own site by creating a similar structure with your app's specifics. Or do you create your model, etc. within those directories, thus the sample should be duplicating some code which it seems not to be. ... Gordon |
|
From: <ben...@id...> - 2004-05-22 13:02:22
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Matthew P. <pa...@dm...> - 2004-04-27 14:28:09
|
Although at least one project was successfully developed using the PHP Doulos Web Application Framework, its development has been discontinued. This conclusion has been reached upon realizing that J2EE provides a much more excellent solution to creating enterprise applications than Doulos could ever hope to be in either Python or PHP. See the doulos-devel list for more decision-making details. Development in J2EE of a unified administrative suite for non-profits has commenced at http://daniel.sourceforge.net/ ______________________________________________________________ Matthew Patton pa...@dm... DiscipleMakers Headquarters: (814)234-7975 x32 ------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ Doulos-announce mailing list Dou...@li... https://lists.sourceforge.net/lists/listinfo/doulos-announce |
|
From: Chris <de...@op...> - 2004-04-19 19:29:47
|
On Monday 19 April 2004 3:13, Jason Maas wrote: > Have you guys seen the JAG project? It sounds interesting: I came across that last night, among a couple other similar projects. Looks interesting indeed. It excites me to know there are so many RAD tools out there for minimizing the "busy work" part of typical J2EE development. Keep me posted on what your research turns up and I'll do the same. (: Chris |
|
From: Jason M. <ma...@dm...> - 2004-04-19 19:13:45
|
Hi there, Have you guys seen the JAG project? It sounds interesting: http://jag.sourceforge.net/ Jason |
|
From: Jason M. <ma...@dm...> - 2004-04-05 16:47:59
|
Hi Chris, On Mon, 5 Apr 2004, Chris wrote: >hahah. Yeah, Java books are huge. (: BTW, what's the name of that >FOSS related book? I would be interested what it says about the >various tools (like the Eclipse IDE) which are aimed at taking some >of the drudgery out of Java/J2EE development. J2EE Open Source Toolkit: Building an Enterprise Platform with Open Source Tools (Java Open Source Library) http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471444359.html Long enough title? =) I also noticed a couple more books on the Wiley Press website that sound interesting (note that I know nothing about them other than the title and descriptions): J2EE Development without EJB http://www.wiley.com/WileyCDA/WileyTitle/productCd-0764558315.html J2EE AntiPatterns http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471146153.html >That'd be cool. Actually 1-4 might be more reasonable for me.. I believe that Matt is going to work out what works best for all of us and email you separately about it. I'm looking forward to it! Jason |
|
From: Chris <de...@op...> - 2004-04-05 07:09:27
|
On Sunday 04 April 2004 11:12, you wrote: > You could have fooled me since you've written a couple falsehoods > and exaggerations about Python over the course of this discussion. Not really. Most of my Python info was from their own website and the rest from some recent "language benchmarks," including some that used Psyco for optimization. > By the time that "THOUSANDS" of organizations are using > GNUeInfoDoulosCalendula I guarantee you that the "importance ratio" > of performance/productivity will be skewed even more in Python's > favor or I'll give you your money back. =) Sure, this is a basic law of computing. But it won't be that long before thousands are using it. InfoCentral already has an estimated 300-400 users with only Freshmeat for advertisement and it's still pretty limited as an app in my book. > I'm still not convinced about how much of J2EE would need to be > reinvented, and if so whether it would need to be done "first". > But that's just me. Why re-invent / pick complete toolsets from the start? Because the needs don't change and you just end up re-writing later, which is wasteful if avoidable. I don't want another PHP experience! > Part of what's going on is that Python is just hands down the > coolest language I've ever met and I can't imagine wanting to > develop using anything else. I can really relate to a Bruce Eckels > quote from that interview: > So that sort of thing is a main motivator behind my Python > lobbying. Sure, Python is great for productivity and it's quite slick. It's just, from all indication, not for enterprise apps YET. (ie. in real life, nobody uses it for this so why would it suddenly work for us?) But yeah.. use Python for everything else if you like. (Well, except system level stuff, GUI toolkits, math heavy code, etc.) > >Did you read the article I provided all the way through? > >http://www.javaworld.com/javaworld/jw-10-1998/jw-10-beans.html > > Yes. Like most Java/J2EE stuff it seemed pretty hung up on using > Java terminology and marketing terms to describe what's going on. > It sounds like the "EJB framework" is a plugin architecture API and > the rest is OOP over a network. It's hard to understand the J2EE > world without already being a J2EE developer. Yes, EJB is a 'plugin architecture'.. but it's what you plug *into* that makes it powerful: the EJB container services that provide the needed enterprise-class functionality. (all those '-ities') Here's yet another explanation: The purpose of EJB is so that you can just write your business logic and mostly forget about the plumbing of the application server. > Alright, alright...I just reserved a couple J2EE books from the PSU > libraries. =) One is all about using FOSS J2EE tools to build > apps (sound applicable?) and the other one was the best sounding > one about EJB technology among the books not checked out. Another > J2EE book I saw is called the "J2EE Developer's Handbook" and it > weighs in at 1486 pages. Ouch. I guess they thought "handbook" > sounded friendlier than "forkliftbook". =) hahah. Yeah, Java books are huge. (: BTW, what's the name of that FOSS related book? I would be interested what it says about the various tools (like the Eclipse IDE) which are aimed at taking some of the drudgery out of Java/J2EE development. > Sounds like a very interesting project. Thanks for the link! There > is some mention of the features you didn't see in their > FEATURES.txt document. I wish this project was more mature. If it was closer than it looks to being usable I'd say it might be worth considering helping out. But it seems to be aimed at Zope X3 too, which means double the experimental code.. And it still doesn't provide as many "-ities" as EJB or other solutions.. (-: > Wow, that was quick! I haven't talked to the other guys yet, but > I'd love to meet with you. I normally have meetings from about > 12:30-3:30 on Thursday afternoon, but if 12-3 is the best time for > you I could probably shuffle things around a bit to get at least > some time with you. Let's see what the other guys think. That'd be cool. Actually 1-4 might be more reasonable for me.. Chris |
|
From: Chris <de...@op...> - 2004-04-05 06:07:14
|
On Sunday 04 April 2004 10:16, you wrote: > I think you've brought up something here that is worth discussing > and all too often forgotten by us computer nerds: our "customers". > In other words, who is this software for and what do they need? Yes, this is a good point and worth discussing.. > A couple customers that come to mind quickly are Chris Gebhardt and > DiscipleMakers. =) With regards to me being a "customer," I do not currently use InfoCentral for my own purposes and my home church does not use it either. However, I do plan to provide consulting and "pay to prioritize development" services for InfoCentral in the not so distant future. So, in a way, I am representing the needs of my future clients as well as the general needs I see. I have researched these quite thoroughly and I also have first hand experience working in a medium sized church's offices. > Also, a main goal of our software development > effort is to produce software that other ministries like DM can use > to help further the kingdom of Christ. (And since it'll be open > source then whoever wants to can use it as well (i.e. non-Christian > non-profits, etc).) My ultimate goal--my career notwithstanding--is that one day NO church or Christian organization will be required to spend a dime on computer software. That's an ambitious goal, I realize, but it is fully possible with enough collaboration and the right approach. > Now, almost by definition our target audience is small organizations > that can't afford to buy/install/administer some big fancy app. If > they could afford the big guns then they'd be off doing that. > What I'm trying to say is that I think the organizations that will > be most interested in the fruits of our efforts are smaller > organizations. These statements I don't agree with, but first there are too many undefined variables here: "small organizations": I would call ~300 or less members a "small church" although this is quite arbitrary. Small churches typically have a minimal staff and minimal software needs. Many still use spreadsheets and the rest use lousy $100-500 off-the-shelf church management tools that only do the basics and typically run on a single workstation computer. They certainly do not have a full-time administrator and rely primarily on volunteers if something breaks. "buy/install/administer": really there are 3 costs here... - For our purposes, "buy" refers to hardware required -- can they use that donated P3-500 with 256Mb. RAM as a server? Or maybe the software can run off a hosting provider which costs $5-10/month. - "install" refers to whether they need to pay somebody to help them set up the software. If they already have their own admin, this is never an issue. - "administer" refers to ongoing costs, typically related to failures but also perhaps advanced features which may need reconfigured from time to time. "big fancy app" / "big guns": software which requires more skill to install than extracting an archive and/or running an install script. Typically this software requires a slightly beefier server to run well. So, having this in mind, the correct solution for most small organizations is something like InfoCentral, written in PHP scripts. It is trivially easy to install, has minimal requirements (PHP and MySQL), and has minimal upkeep (just upgrades, if needed). The majority of its users are either running off a cheap web hosting provider or else they are using an old Linux or Windows machine as a local server. Trust me.. most don't have a clue what they're doing. They need something *very* simple. Python is not a simple solution to install by any measure and you'll be hard pressed to find a cheap web hosting provider that supports it -- let alone enables you to install an application server. (Unless you actually buy rack space, of course, which is expensive) So basically, the choice to go with either Python or Java is a choice to force users to have their own server and know a little bit what they're doing regardless. This automatically eliminates the smallest organizations, but that's ok. Their needs are already met by the old PHP InfoCentral and perhaps a spreadsheet or Quickbooks / Peachtree / etc. for finances. Now lets consider some other "categories": "medium-small sized organizations": perhaps 300-1000 members. Most either have a part time administrator or else they have contracted some person or company to do work as needed. They have enough resources to buy a nice but not extravagant server and they have skills available to install most software. "medium organizations": perhaps 1000-6000 members. Typically they have a full time administrator. Hardware and skills are almost a non-issue, but there is still a pressing need to keep costs as low as possible. (and hey, wouldn't it be great if the technology was reliable enough they didn't need that full-time admin?) "large organizations": perhaps 6000+ members. Cost is no object when it comes to meeting technology needs. (although hopefully they are still good stewards of resources..) The two "medium" sizes represent the vast majority of churches. Most are using slightly higher-end church software like ACS or Shelby. (roughly $2000-$10000 + support) These are windows GUI programs, client/server, 2-tier database apps, nothing that fancy. (but they also don't do very much and they're not customizable..) For other needs, they use a plethora of other software. Large organizations (big churches, nationwide ministries, etc.) are more likely to use heavy-duty, highly-expensive solutions like PeopleSoft, etc. which aren't even "church" software -- they're just flexible enough to cover church database needs. OK, so after all that, if we want to have the most impact, we should aim for meeting the needs of medium sized churches/orgs. But we shouldn't just meet the needs and maintain the (pitiful) status quo.. we should set a new standard for quality church software such that there isn't even a question which solution is best. Over time, this software can improve to the point where the largest organizations start using it as well -- largely because it is open and customizable, but the cost is a nice bonus too. > I think it's a worthy goal to seek to be as good or > better than the Big Apps (TM) that huge mega-ministries are buying, > but those organizations just aren't going to be that interested in > us until we're better than their mammoth apps. What I want to do is bring "Big Apps" to medium sized organizations for free and with reasonable installation requirements. In fact, I want to do better than the traditional "Big Apps" by creating a solution that is more than just a database. The patchwork solutions currently in use are junk IMO. Medium sized churches end up using mid-priced software from a dozen vendors in attempt to meet their needs. None of it integrates, most of it is unreliable, the user interfaces are unintuitive and varied, and the resulting maintenance is through the roof. As for what this end result software I want to create looks like.. The obvious stuff: - Membership / relationship database - Complete finance / fundraising / accounting solution Less obvious stuff: - Public / Intranet website content management (largely automated and integrated with other tools / document management) - Website services for members (mail, online giving, reservations, tools for leaders, portals for youth or other groups, etc.) - Scheduling, inventory, and facility maintenance - Point of sale (bookstore, etc.) - Information sharing with sister churches or affiliations (denominations need this, esp. for finances) - Groupware tools for staff - Export of church material (sermons, study guides, articles, etc.) to larger Christian websites via web services. - Integration with phone system for menus, voicemail, info hotline, automated calling, etc. - "Gadget" category: Kiosks, Handheld PCs, control of campus security / HVAC / lighting / A/V / roadside marquee / etc. I should point out that I've see ALL of this kinda stuff in ACTUAL use already. But it's not integrated in an all-in-one solution that integrates together and "just works." With all this in mind, perhaps you have a better understanding why I am insisting upon "enterprise-class" design. > I think it's worth mentioning here and keeping in mind that our > software needs to be useful and not overwhelming for small > organizations like DM and small churches. They need to be able to > use it for their needs without a full-time sysadmin or programmer. Yes, the software should be modular enough to scale down to much smaller needs. Many churches just need a basic membership and donations database and that's fine -- just install those modules. However, I do not believe it is too much for most organizations to install Python or JBoss. Though in terms of "small" organizations, yours is probably an exception with regards to available technical skills. (: Chris |
|
From: Jason M. <ma...@dm...> - 2004-04-05 03:12:20
|
Hi Chris, Ok, here's the rest... =) On Sun, 4 Apr 2004, Chris wrote: >I'm not anti-Python. You could have fooled me since you've written a couple falsehoods and exaggerations about Python over the course of this discussion. >I don't quite get your reasoning here. If we were developing an >application that ONLY we would use (or if we were selling proprietary >software..), then sure, rapid development would be far more important >than performance. But if THOUSANDS of organizations are using our >software, that performance difference means a whole lot of extra >hardware being bought -- millions of dollars worth. So I think >performance is still relevant.. it's just a question of *how* >relevant. By the time that "THOUSANDS" of organizations are using GNUeInfoDoulosCalendula I guarantee you that the "importance ratio" of performance/productivity will be skewed even more in Python's favor or I'll give you your money back. =) >Now, here's the more immediate consideration: Python doesn't have >what we need *right now.* So where does all that greater >productivity go when you have to re-invent much of J2EE first? I'm still not convinced about how much of J2EE would need to be reinvented, and if so whether it would need to be done "first". But that's just me. >That's all quite valid opinion, but the question remains, at the end >of the day, 'which platform has the tools you need?' Part of what's going on is that Python is just hands down the coolest language I've ever met and I can't imagine wanting to develop using anything else. I can really relate to a Bruce Eckels quote from that interview: I feel Python was designed for the person who is actually doing the programming, to maximize their productivity. And that just makes me feel warm and fuzzy all over. I feel nobody is going to be telling me, "Oh yeah, you have to jump through all these hoops for one reason or another." When you have the experience of really being able to be as productive as possible, then you start to get pissed off at other languages. You think, "Gee, I've been wasting my time with these other languages." -- Bruce Eckels (http://www.artima.com/intv/aboutmeP.html) So that sort of thing is a main motivator behind my Python lobbying. >Did you read the article I provided all the way through? >http://www.javaworld.com/javaworld/jw-10-1998/jw-10-beans.html Yes. Like most Java/J2EE stuff it seemed pretty hung up on using Java terminology and marketing terms to describe what's going on. It sounds like the "EJB framework" is a plugin architecture API and the rest is OOP over a network. It's hard to understand the J2EE world without already being a J2EE developer. >Also, if you have not checked out any EJB books at the library, you >probably should to get a better handle on how they work. (even just >to get ideas..) Alright, alright...I just reserved a couple J2EE books from the PSU libraries. =) One is all about using FOSS J2EE tools to build apps (sound applicable?) and the other one was the best sounding one about EJB technology among the books not checked out. Another J2EE book I saw is called the "J2EE Developer's Handbook" and it weighs in at 1486 pages. Ouch. I guess they thought "handbook" sounded friendlier than "forkliftbook". =) >Because there does exist criticism of EJB among J2EE developers, it is >probably worthwhile to take a closer look whether there are any >better solutions available. One thing I need to investigate is this >whole "Aspect Oriented Programming" thing, which is an alternative to >"component-oriented" design. JBoss seems to be promoting this >lately. Cool. Keep investigating and let us know what you find out. >** THIS JUST IN.. (: >I have *just* found a Python project called PEAK that seems to be >aiming in the right general direction to fill the missing "EJB" hole >in creating a viable Python alternative to J2EE. Sounds like a very interesting project. Thanks for the link! There is some mention of the features you didn't see in their FEATURES.txt document. >If you search for negative opinions about EJB on the web, you're going >to find them. Same with "Linux sucks" (: Very true. However, what caught my eye is that the top links were written by gung-ho J2EE guys, not just Python zealots. =) >Have you tried looking for positive opinions as well to balance things >out? Why bother? ...it's not Python so it must stink. ;) >Hmm.. I'll be in SC to pick up my brother for Easter weekend on >Thursday. Would you guys happen to be available for lunch/chat >around say.. 12:00-3:00? Wow, that was quick! I haven't talked to the other guys yet, but I'd love to meet with you. I normally have meetings from about 12:30-3:30 on Thursday afternoon, but if 12-3 is the best time for you I could probably shuffle things around a bit to get at least some time with you. Let's see what the other guys think. -Jason |
|
From: Jason M. <ma...@dm...> - 2004-04-05 02:16:57
|
Hi Chris, I want to take a little time here to talk about the target audience (aka 'customers' in the business world) for our software. That's why I've changed the subject. I'll respond to the rest of your email after this... On Sun, 4 Apr 2004, Chris wrote: >I don't quite get your reasoning here. If we were developing an >application that ONLY we would use (or if we were selling proprietary >software..), then sure, rapid development would be far more important >than performance. But if THOUSANDS of organizations are using our >software, that performance difference means a whole lot of extra >hardware being bought -- millions of dollars worth. So I think >performance is still relevant.. it's just a question of *how* >relevant. I think you've brought up something here that is worth discussing and all too often forgotten by us computer nerds: our "customers". In other words, who is this software for and what do they need? A couple customers that come to mind quickly are Chris Gebhardt and DiscipleMakers. =) Also, a main goal of our software development effort is to produce software that other ministries like DM can use to help further the kingdom of Christ. (And since it'll be open source then whoever wants to can use it as well (i.e. non-Christian non-profits, etc).) Now, almost by definition our target audience is small organizations that can't afford to buy/install/administer some big fancy app. If they could afford the big guns then they'd be off doing that. What I'm trying to say is that I think the organizations that will be most interested in the fruits of our efforts are smaller organizations. I think it's a worthy goal to seek to be as good or better than the Big Apps (TM) that huge mega-ministries are buying, but those organizations just aren't going to be that interested in us until we're better than their mammoth apps. I think it's worth mentioning here and keeping in mind that our software needs to be useful and not overwhelming for small organizations like DM and small churches. They need to be able to use it for their needs without a full-time sysadmin or programmer. Distributing the app across servers probably isn't going to be a concern for these organizations. To reiterate again: let's keep our customers at the front of our minds and make sure we provide what they want. Any thoughts? Jason |
|
From: Chris <de...@op...> - 2004-04-04 09:03:00
|
On Saturday 03 April 2004 9:12, Jason Maas wrote: > 1. You've got your own anti-Python FUD machine going in 5th gear. I'm not anti-Python. I'm anti-Python for enterprise applications *at this time* due to valid technical deficiencies. (: > 2. Python's performance compared to Java will vary depending on > the task, and it's not always slower. > 3. Much of Python's standard library is written in C (for the > standard "CPython" implementation) so if your task heavily uses > those routines its performance should be quite good. This is true. Some operations in Python are as fast as in Java. However, on average (looking at a complete application), Python is generally said to be significantly slower. In Python's favor, it can be said that some applications do not show the speed difference because they are I/O bound. On the other hand, Python is said to be notoriously slow for handling objects, which we will be doing a lot of. As possible evidence, one of the GNU Enterprise developers told me that performance was awful when they tried to go the completely object oriented approach in developing a framework for writing business logic. Overall, Java IS faster than Python. This is really not up for debate. But regardless, performance is not the primary criteria in deciding the right enterprise platform. Features come first. > 4. Python has its own JIT compiler, called Psyco (psyco.sf.net), > just like the big boys in the Java world. Psyco significantly improves Python's performance but primarily on algorithmic code. I would like to see an analysis of whether it helps much with heavily object oriented software. > All that being said, I still think that sacrificing developer > productivity for CPU performance is a big waste in this day and > age. I don't quite get your reasoning here. If we were developing an application that ONLY we would use (or if we were selling proprietary software..), then sure, rapid development would be far more important than performance. But if THOUSANDS of organizations are using our software, that performance difference means a whole lot of extra hardware being bought -- millions of dollars worth. So I think performance is still relevant.. it's just a question of *how* relevant. Now, here's the more immediate consideration: Python doesn't have what we need *right now.* So where does all that greater productivity go when you have to re-invent much of J2EE first? > Check out this webpage for part 2/4 of an interview with a > programming language author who has gone from C++ to Java to > Python: > http://www.artima.com/intv/prodperfP.html > http://www.artima.com/intv/aboutmeP.html > http://www.artima.com/intv/typingP.html > http://www.artima.com/intv/tippingP.html That's all quite valid opinion, but the question remains, at the end of the day, 'which platform has the tools you need?' > Now I'll share a few of my thoughts about Enterprise JavaBeans and > Containers. > - I still haven't seen a decent introduction of them that explains > how EJBs and Containers actually work on a technical level (most > everything about them tells what they do at a marketing-speak > level). - I suspect that few people that use them actually > understand them - As you've seen, there is a fair amount of > controversy within the world of hard-core J2EE developers about > whether EJBs are even worth using. We should make sure we > understand what's going on there. Did you read the article I provided all the way through? http://www.javaworld.com/javaworld/jw-10-1998/jw-10-beans.html Also, if you have not checked out any EJB books at the library, you probably should to get a better handle on how they work. (even just to get ideas..) Because there does exist criticism of EJB among J2EE developers, it is probably worthwhile to take a closer look whether there are any better solutions available. One thing I need to investigate is this whole "Aspect Oriented Programming" thing, which is an alternative to "component-oriented" design. JBoss seems to be promoting this lately. So anyhow, from that perspective, lets look at what we are aiming for: Objects which: - persist in a managed pool for the purposes of caching, load balancing, failover, etc. - are efficiently and reliably accessible remotely via multiple protocols - are able to be located via some sort of directory service - can participate in application wide transactions - have security provided by their runtime environment There may be other solutions in the Java camp which meet these sort of criteria. (AOP + POJO?) However, I have not yet seen anything in the Python camp that provides what I'm looking for. ** THIS JUST IN.. (: I have *just* found a Python project called PEAK that seems to be aiming in the right general direction to fill the missing "EJB" hole in creating a viable Python alternative to J2EE. Basically they are aiming to provide similar functionality to EJB entity beans and the JNDI naming service and then plug into Zope for most of the rest of the functionality. Unfortunately it is also alpha code, the documentation is really sketchy, and I see no mention of how they plan to handle caching, load balancing, failover, and other enterprise services that EJB containers provide. So maybe in 5 years.. but this is not something we can use today by the looks of it. But at least it's a step in the right direction.. competition is good. (: http://peak.telecommunity.com/ > If EJBs aren't so great, then what's left about J2EE that's so > special? EJB is currently what most interests me about J2EE. On the other hand, the other components like RMI, JSP, Servlets, JDBC, and the various XML processing tools are currently far more mature and full-featured than their Python counterparts. The same is true of related but non-J2EE-spec tools such as Hibernate. (on the positive side, at least the Python camp is further along at writing counterparts for these components..) And if EJB doesn't work, there are alternatives that also fit within the J2EE framework.. so it's not "just about EJB" regardless. > - check out the first three results on this page: > http://www.google.com/search?q=ejb+crap If you search for negative opinions about EJB on the web, you're going to find them. Same with "Linux sucks" (: Have you tried looking for positive opinions as well to balance things out? I would also note that some of those sources are older and pre-EJB 2.0. This may or may not be relevant to the arguments made. > Regarding the possibility of getting together in person: when are > you coming to State College? =) Let us know ahead of time and it > would be great to meet you. One of us could probably house you > while you're here too. Hmm.. I'll be in SC to pick up my brother for Easter weekend on Thursday. Would you guys happen to be available for lunch/chat around say.. 12:00-3:00? Chris |
|
From: Jason M. <ma...@dm...> - 2004-04-04 02:12:29
|
Hi Chris, I'm finally responding to your last few emails in the Python vs. J2EE debate. =) Regarding your thoughts on Python vs. Java run-time performance I'll say a few things. 1. You've got your own anti-Python FUD machine going in 5th gear. =) 2. Python's performance compared to Java will vary depending on the task, and it's not always slower. 3. Much of Python's standard library is written in C (for the standard "CPython" implementation) so if your task heavily uses those routines its performance should be quite good. 4. Python has its own JIT compiler, called Psyco (psyco.sf.net), just like the big boys in the Java world. All that being said, I still think that sacrificing developer productivity for CPU performance is a big waste in this day and age. Check out this webpage for part 2/4 of an interview with a programming language author who has gone from C++ to Java to Python: http://www.artima.com/intv/prodperfP.html Here are links to parts 1, 3, and 4 of that same interview: http://www.artima.com/intv/aboutmeP.html http://www.artima.com/intv/typingP.html http://www.artima.com/intv/tippingP.html Now I'll share a few of my thoughts about Enterprise JavaBeans and Containers. - I still haven't seen a decent introduction of them that explains how EJBs and Containers actually work on a technical level (most everything about them tells what they do at a marketing-speak level). - I suspect that few people that use them actually understand them - As you've seen, there is a fair amount of controversy within the world of hard-core J2EE developers about whether EJBs are even worth using. We should make sure we understand what's going on there. If EJBs aren't so great, then what's left about J2EE that's so special? - check out the first three results on this page: http://www.google.com/search?q=ejb+crap Regarding the possibility of getting together in person: when are you coming to State College? =) Let us know ahead of time and it would be great to meet you. One of us could probably house you while you're here too. Jason |
|
From: Chris <de...@op...> - 2004-04-03 00:17:58
|
Good summary.. Here's just a couple final points I thought should be
noted.
On Thursday 01 April 2004 2:43, Matthew Patton wrote:
> Benefits of J2EE:
> -----------------
- Performance. Java itself is many times faster than Python (usually
an order of magnitude). This means you can do a lot more with less
hardware -- even if that's just more layers of abstraction in the
framework. A Python solution that did everything that J2EE does
would likely be terribly slow. J2EE also has many performance
optimizing techniques already (caching, etc.)
> - 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
> - Many templating options
What you mention here refers to options for building the web client.
It should also be noted that there are now good options for writing
GUI clients as well. You had mentioned UI clunkiness as a drawback
below, but most likely you are referring to Java apps you've seen
that use the ugly, outdated AWT ('advanced' windowing toolkit). The
new official GUI framework is Swing and you can find a lot of related
projects on Freshmeat. Perhaps the best option yet is Java + XUL:
rich clients that run through Mozilla.
http://www.mozilla.org/projects/xul/joy-of-xul.html
http://luxor-xul.sourceforge.net/
http://thinlet.sourceforge.net/index.html
http://swingwt.sourceforge.net/
http://uic.sourceforge.net/
> Costs of J2EE:
> --------------
> - With JBoss we would have to pay for docs beyond the tutorial (may
> not be necessary for our purposes)
There are 3rd party documentation sources for JBoss also. One I just
heard of goes along with the O'Reilly EJB book, which I'll probably
get at some point regardless.
http://www.oreilly.com/catalog/entjbeans3/workbooks/index.html
One last consideration: I have already firmly decided upon J2EE for
InfoCentral, so if you go that route, you'll have extra helpers. (-:
Currently myself, a friend of mine, and possibly two others from the
IC forum.. One other thing to consider is that, if you need a
solution sooner for some basic stuff, you could always add some quick
and dirty features to InfoCentral and then re-implement later in J2EE
once the codebase is usable. Version 1.3, the last version to use
PHP, is currently in the works and should clean things up enough to
be more easily extensible.
Chris
|
|
From: Chris <de...@op...> - 2004-04-02 07:48:35
|
On Thursday 01 April 2004 10:59, Jason Maas wrote: > Are you on the Calendula mailing list? Matt posted there about > J2EE vs. Python stuff and a few interesting responses have been > posted there. I'm not on the list, but I just checked out the discussion. It sounds like Darryl is set on writing a simple, lightweight application for a specific limited purpose (fundraising). If that's what he wants then J2EE is not his answer. Of course, the other side is that Calendula will be rapidly eclipsed by the full-featured heavyweight application that we've been discussing. (once it gets off the ground of course..) Tom P's points about Java/J2EE are good. It is clear that he has real world experience with it. One thing I would question regards the discussion of EJB's. The alternative, as he mentions, is to use ORM tools like Hibernate by themselves to implement the persistence layer. In my research, I have found numerous projects that go this route, but this bothers me because you lose all the nice enterprise stuff that the EJB container gives you. (he mentions this as well..) It is true that EJB has a high overhead, but it seems mostly justified by what you get in return. It also sounds as if this drawback can be mitigated by proper design. As a real-world reference, I have heard of companies who write their core apps using regular JB's + ORM tools and then later scramble to re-write using EJB for added scalability and design flexibility. Chris |
|
From: Jason M. <ma...@dm...> - 2004-04-02 03:59:53
|
Hi Chris, Are you on the Calendula mailing list? Matt posted there about J2EE vs. Python stuff and a few interesting responses have been posted there. If you're not on the list you can check out the action here: http://list.fudosys.com/pipermail/calendula-devel/2004-April/date.html Jason |
|
From: Matthew P. <pa...@dm...> - 2004-04-01 19:43:46
|
Hello Chris and Jason, Thank you both for your excellent thoughts and research! I have been lurking here but listening attentively, and I felt like now might be a good time to jump in and give a summary of everything that's been said. I have phrased it in the form of a cost-benefit analysis for either side: Python or J2EE: 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 for a server to serve up objects and handle authentication - Modeling 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 - Need to be able to pass objects, reference params at the bare minimum - A more advanced feature would be allowing more than just static methods to be called (i.e., remote references to instances of objects on the server) - Client Frameworks - All existing frameworks are too immature - 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 - 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. 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 - Many templating options - Enterprise Java Beans (EJB) are extremely powerful - Allow encapsulation of how data is stored (hides this from client) - 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 - 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.) - 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 my own research and both of your excellent input. 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. At this point, I'd say we (here at DM) are getting close to making a decision as to which direction to pursue. We'll keep you posted, Chris. Thanks, Matt ______________________________________________________________ Matthew Patton pa...@dm... DiscipleMakers Headquarters: (814)234-7975 x32 |
|
From: Chris <de...@op...> - 2004-04-01 09:43:45
|
On Sunday 28 March 2004 5:05, you wrote: > Fair enough, but also note that his bias tends to leave less room > for trouble later *in general* (may not apply in this case). In > other words, I think being biased towards Free software is a good > bias to have. =) I certainly agree. If I wasn't so certain that Java would be available in pure Open Source form in the near future, I wouldn't be considering it now. Now that Sun has formally declared that none of their *own* code will be opened, I hope ESR will take his advocacy to other companies with a vested interest in having an open Java sooner than Kaffe and GNU ClassPath are currently able to produce. > Personally, I'm not really worried about computational performance. > IMHO, ESR makes a great point in AoUP about hardware being cheap > and people not, and focusing on the most maintainable code. I think this argument really only works for throw-away code developed for internal business purposes only. In that case, developer time is, in fact, more expensive than hardware. We, on the other hand, are looking to produce top quality code that literally thousands of organizations will use. If Python is on average 5x slower, that means they have to purchase 5x more hardware. Then multiply that by thousands of churches and organizations. All of a sudden, that's a really significant difference that greatly outweighs the slight time cost benefit of using Python. On a side note, any money spent on hardware is money that *could* have been donated to our project to perhaps hire people full time. (thinking long term here..) > He makes a good argument for the smallest amount of code possible > (i.e. the highest level language possible) because the number of > bugs roughly corresponds to the amount of code, regardless of the > language used. All that being said, there are plenty of "easy" > ways to increase software run-time performance short of using a > lower-level language. Java is pretty high-level, but not as much > as Python. While I agree that, overall, shorter code tends to have fewer bugs, it is important to distinguish between source textfile lines and actual functional lines of code. Most of the examples I've seen which try to make a point that Python code is "shorter" try to fault Java for the use of curly braces and other non-functional syntax and, of course, variable and class declarations. Just because a piece of Java code is twice the length (in lines), does not mean the language requires twice as much coding effort and hence contains more room for bugs. When you get down to it, there's not that much difference. In places where there is, it's mostly because Java gives you more control -- and thus flexibility and performance tweakability. It should also be pointed out that Java has an enormous class library, such that many common things do not need written by hand. > Ok, that's good to know. What are some of the other enterprise > frameworks available in the Java world? The other frameworks are typically custom jobs or hybrids of J2EE and other Java tools. Regardless, J2EE seems to be the industry accepted standard and for good reason. Incidentally, Java's most popular equivalent to Zope, Webware, and other web (not enterprise) application frameworks is Struts, which is part of the Apache Jakarta project. I've never used it myself but web developer friends of mine seem to hold a high opinion of it. > I think we're homing in on the target, but your definition sounds > more like a generic definition for "enterprise framework" than a > definition of J2EE. More on J2EE further below... That's true. I was pretty generic because I am still learning J2EE's implementation details. I have a high-level knowledge of what the components of J2EE accomplish, but not specifics yet. As for a definition of "J2EE" .. it's an enterprise application framework *specification* that seeks to meet the criteria given previously. Those criteria define it and set it apart from other software. The rest is just marketing and buzzwords. (: Here's the definition given by the book I'm reading, paraphrased: "The purpose of J2EE is to create a clear, unified platform for developing distributed applications using a component-based model." The key terms are 'distributed' and 'component-based.' > I agree that it's probably important to make > sure that whatever road we head down doesn't negate any of those > requirements, however I feel quite strongly that we don't need to > provide all of that on the first try. In other words, we want to > make all those requirements possible, but not necessarily > implemented right away. I think the open source model of iterative > development and throwing out things that don't work is a good one. > If we try to achieve perfection and feature completeness all up > front then we're setting ourselves up for disaster. The beauty of J2EE is that all the really complicated "plumbing" is already done. So when you use J2EE as intended, you automatically fulfil the enterprise requirements. That's what sets it apart. You don't have to write our own system for distributed transactions, remote objects, managing and deploying web services, failover, load balancing, component hot-swapping, security, etc. because that's all part of the architecture already. This is the part that most people miss. Let me re-iterate: Most people are looking for *web* application servers, not *enterprise* application servers when they try to compare Python to J2EE. You cannot go by what these people say because they do NOT have enterprise criteria in mind. > I'm really glad that you've done so much thinking about these > problems and the best way to solve them. I think it would be neat > to get together in person sometime - I'd love to hear more of what > you have written down. I only live 3 hours away from State College and my brother is now a PSU student. So maybe some weekend I can come up to visit him and we can meet up. A lot of this planning and brainstorming stuff would be much easier in person! :) > Now let's dig into what you wrote there a little more. Which parts > of J2EE excite you so much? There's quite a bit of what Sun calls > "J2EE" that Python and other languages do just fine. It's kinda like a presidential campaign.. the candidates often seem to have the same platform and use the same politicized lingo, but under the surface there is a huge divergence. The tough part is digging down enough to find real answers. > I want to find out exactly what is so great about J2EE so we can > know why it's such a good fit for us. I'll try to go through this point by point.. this is going to end up pretty long, but they say the best way to really learn something is to explain it to somebody else. (-: > Components > ---------- > - Client > - J2EE clients are either a "web client" or Java application No, actually a J2EE application server can talk to many more different types of clients than these two. The most notable other options are web services and CORBA. Both of these are already built in. In the case of web services, it is pretty trivial to deploy them once you've written your business logic into EJB's. > - this part translates easily to a non-J2EE environment (need I > say more?) Sure, it translates, but I wouldn't necessarily say "easily". Python doesn't really have any standard for writing business objects and then connecting them to various remote protocols. That's not to say it can't be done, but there's a lot more gluing involved, whereas J2EE is a solid standard that is guaranteed to work. > - Web Components > - Servlets (aka CGI or server side scripts) - nothing special > here > - Java Server Pages (JSP) > - mixing code & HTML like PHP & the various Python mechanisms > (PSP, etc) > - again, nothing special here Python has a lot of options in this field so this is not a problem. I would, however, question the maturity of these options. There are many competing "PSP" and "Python Servlet" standards / projects. I will have to say, from what I've seen so far, that JSP seems to blow away even the fairly mature PHP. Also, JSP's performance, formerly quite lacking, is now superior to all of the other *SP template-style tools. > - Business Components > - Enterprise JavaBeans (EJB) - basically objects you can use > remotely with standardized interfaces (method names, etc) > - now we're getting more interesting, but other platforms can > do remote procedure calls & remotely callable objects EJB's are a whole lot more than just objects that can be used remotely. They are the very core of J2EE and there are quite large books dedicated to them alone. EJB's reside in / are managed by an EJB Container. The container provides enterprise services and access to the infrastructure J2EE API's. This article is a good introduction to the basics of EJB. It does not get into detail about the enterprise services available, however. http://www.javaworld.com/javaworld/jw-10-1998/jw-10-beans.html > - 3 types of beans: Session, Entity, and Message-Driven > - Session beans handle a connection with a particular client > - nothing revolutionary sounding here Actually, session beans are not so trivial. We're not talking about an equivalent to the PHP $_SESSION array here. While I have not studied them in detail, session beans appear to provide a majority of the business logic and "Controller" part of the application. > - Entity beans handle mapping program data into the database > - basically O-R mapping? Entity beans are used for managing *any* persistant data. They represent shared, transactional data. Whether you use an O-R mapper (or a relational database for that matter) is up to you. Regardless, what they provide is far more than mapping from a persistant store to an object. Entity beans are managed by the container for the purposes of concurrency, transactions, caching, security, exemption handling, etc. -- all that really ugly plumbing stuff that you'd have write your own solution for in Python. > - Message-Driven beans seem kinda vague, not sure what they do Messaging refers to asynchronous but reliable delivery of information. I believe these beans are primarily meant for interoperability purposes but you can also do what my book describes as "publish-subscribe" architecture where components listen for broadcast messages of a certain type. As this is a newer J2EE technology, I'll have to look on the web for more detail. > Containers > ---------- > Their description is a little vague, but it sounds like they're > basically the code that actually talks XML-RPC, DNS, LDAP, PAM, > etc. As far as I can tell there's nothing too special here - other > platforms have libraries to talk those protocols for you. As said before, containers manage beans and provide access to J2EE APIs and services. They have nothing to do with actually talking the protocols you mentioned. > Web Services > ------------ > Not a whole lot to say here. Python and other platforms can handle > all the web, XML, XML-RPC, SOAP, etc stuff just fine via their > libraries. As said before, the hard part becomes mapping those web services protocols to your business objects. J2EE does this with ease. With Python, you have to hack out your own solutions. > J2EE 1.4 APIs > ------------- > Now we get to the list of acronyms Sun has bunched up in their J2EE > diagrams: I already covered most of this, so I'll just leave what's left.. > - Java Message Service (JMS) - distributed communications > - not sure if this is special or what the analog is on other > platforms As with message beans, this is something I'm not entirely familiar with yet. I think a rough analogy would be TCP/IP, but instead of for network packets, it's for application data and events and there's always something of a hub-and-spoke architecture. There seem to be many similar concepts: routing, TTL, QoS, queueing, etc. Need to read more on all this.. One such use might be as follows: You need to have a message pop up on all logged in clients.. "Fire in the server room!" ..probably that cpu-hog Python server overheated again.. hehe. sorry, couldn't resist. :-P > - Java Transaction API (JTA) - lets you couple operations > as a single transaction, but doesn't sound hugely interesting since > the DBMS can do that too (PostgreSQL can anyway) JTA is for application wide transactions and is not just RDBMS related. Remember that we're talking to objects at this level. Part of the transaction could include accessing data sources other than the primary database (ldap, web services, etc.) or even doing stuff like sending an email.. or uh.. sending a message to turn on the Halon to extinguish that flaming Python server. (: ok, it's 4am and I'm slap-happy.. > - JavaMail API - email sending library - nothing special here Actually it does SMTP, IMAP, POP3, and MIME, so it's for sending *and* receiving. And again, it's quite robust and well tested and integrates with all the transaction stuff.. etc. > - Java API for XML Processing (JAXP) - plenty of support for > parsing XML on other platforms > - Java API for XML-Based RPC (JAX-RPC) - XML-RPC and SOAP; nothing > special - SOAP with Attachments API for Java (SAAJ) - lower level > API that JAX-RPC uses; tutorial basically says to use JAX-RPC and > not this - Java API for XML Registries (JAXR) - Python has UDDI > support Yes, this kinda stuff is available on any platform. Again, with the web-services stuff, there's a lot of robust infrastructure already built so you don't have to. > - J2EE Connector Architecture - connections to DBMSes; > nothing special - JDBC API - connections to DBMSes Yeah.. pretty much like any database wrapper > - Java Naming and Directory Interface (JNDI) - standard API for > resolving names into things, i.e. DNS, LDAP, RMI objects, etc - > sounds useful but not necessary JNDI is used to publish and find resources in a distributed enterprise application. Its functionality is most definitely necessary. See the description in the EJB article.. > - Java Authentication and Authorization Service (JAAS) - Pluggable > Authentication Modules (PAM); Python has PAM support too PAM is just one part of JAAS. It's more of a complete security framework, again, which integrates throughout the entire application. > The only things that > look interesting to me are Enterprise JavaBeans and Containers, and > those mostly because I understand the least and they sound like the > most "enterprisey" (not just "web services" stuff). Please let me > know if you know exactly what EJB and Containers are. Well, you were certainly on the right track there with EJB and containers. (: OK.. that was a long one! Let me know if my explanations are insufficient. Of course, I would recommend getting a J2EE book or two at your local library if you really want to dig in further. I'm finding that once you get beyond a certain point, all this stuff really starts to click and make sense. Being comfortable with the acronyms, terminology, and basic concepts goes a long way. Chris |
|
From: Chris <de...@op...> - 2004-03-29 22:16:01
|
On Monday 29 March 2004 10:31, Jason Maas wrote: > Maybe there is a reason why there is such an anti-Java attitude in > the OSS world. Maybe, just maybe, legions of OSS developers > haven't been brainwashed to be anti-Java but actually don't like it > based on its technical merits. That's what I'm trying to find out. I think it's more the fact that, in its early days during the dotCom era, Java was indeed weak in a lot of areas. It was quite slow, the standards were not solidified, its complexity was unwarranted for small web-only tasks, Sun's marketing was full of fluff, and a lot of fly-by-night dotCom companies tried to shoehorn it into everything imaginable because it was supposed to be the "next big thing." So a lot of people were left with a bad taste in their mouth so to speak. Java today is completely different than the Java of 1995-2000. It has matured both as a language and as a development platform. > Google for "jboss sun legal" (without the quotes) and see what you > find - a number of articles about Sun giving JBoss a hard time > including one with this quote: "JBoss, an open-source software > company, for years has been at odds with Java steward Sun, which > has even threatened legal action against JBoss." Here is that > article: This was a minor trademark issue and it was peaceably resolved. See this article (http://news.com.com/2100-7345-5108445.html) for the full story or note the clips below which summarize the key points. "Sun complained that JBoss was claiming to provide a J2EE-compliant application server, even though JBoss had not invested the time and money required to undergo the certification tests. JBoss, meanwhile, complained that Sun was asking for too much money." "Sun executives said JBoss and Geronimo were able to purchase the license because of the changes Sun had made to its licensing system in order ** to accommodate open-source projects.**" (emphasis mine) What should be noted is that the point of contention was _not the implementation itself_ but rather the fact that JBoss was claiming it was J2EE compliant without having verified this fact with Sun. > We need to define on a technical level what an "enterprise > framework" is because Sun is pushing the web framework stuff in > J2EE 1.4 as hard as they can as being "enterprise" stuff. Yes.. here's the difference: the web framework components of J2EE (JSP and Servlets) are a *part* of the whole enterprise solution. Python has rough equivalents to JSP and Servlets (such as PSP), but they do NOT plug into a larger enterprise application framework. They stand alone as merely tools to build a web application. In this arena, PHP and some Perl-based projects are also competitors. It is up for separate debate which solution is best for those who only need to design a web application. .. more reading/research to do before I can adequately answer the "big email" but it won't be too much longer. :) Chris |
|
From: Jason M. <ma...@dm...> - 2004-03-29 15:31:42
|
Hi Chris, Thanks for your quick replies. On Mon, 29 Mar 2004, Chris wrote: >It burns me up that so much anti-Java FUD abounds within the Open Source >community. Maybe there is a reason why there is such an anti-Java attitude in the OSS world. Maybe, just maybe, legions of OSS developers haven't been brainwashed to be anti-Java but actually don't like it based on its technical merits. That's what I'm trying to find out. >Anyone who, today, can write this about Java: "I'm not particularly a >firm believer in Java. Actually, I think that to this point most of >what has been said about it has been marketing droid snake-oil." > >... clearly has no understanding whatsoever of the language and is in >severe disconnect with the reality that Java/J2EE is an enormous >success in the enterprise server arena. Its ONLY viable competitor >today is dotNET. I don't think that I agree with what you wrote, but I'll wait to see what you think of my J2EE analysis. >Then he goes on to expound common myths such as: "It seems fairly >likely that Sun might mount legal challenges to anyone attempting to >implement a system interoperable with JDK 1.2 as free software." > >This, again, is entirely false. First, there are already numerous >non-Sun Java 1.2+ implementations (including closed-source ones) and >none of them have been legally harassed. Google for "jboss sun legal" (without the quotes) and see what you find - a number of articles about Sun giving JBoss a hard time including one with this quote: "JBoss, an open-source software company, for years has been at odds with Java steward Sun, which has even threatened legal action against JBoss." Here is that article: http://news.zdnet.co.uk/software/developer/0,39020387,39116561,00.htm It was written about half a year ago so this isn't old news. It seems that JBoss has gotten out of some of the trouble by coughing up a $5000 fee to Sun to be part of the Sun-controlled "Java Community Process". >His discussion of J2EE is, again, severely lacking in understanding. >"J2EE attempts to address the same kinds of areas that various Python >Web frameworks" bzzz.. wrong. Java attempts to address far bigger >needs than "web frameworks," which is all that Python has managed >thus far. I'm seeing a trend of misunderstanding here.. We need to define on a technical level what an "enterprise framework" is because Sun is pushing the web framework stuff in J2EE 1.4 as hard as they can as being "enterprise" stuff. >I will finish my response to the previous email when I get a chance. >I am doing more research into the specifics of EJB's and how they >relate to implemention the distributed transactions, etc. Great, I'm looking forward to it! Jason |
|
From: Chris <de...@op...> - 2004-03-29 05:36:09
|
On Sunday 28 March 2004 11:31, Jason Maas wrote: > Here is a web page that has some short but sweet overview info > about Java. It has some info and links about the licensing > concerns, and a little bit about J2EE. Be sure to check out > sections 1.1, 1.2, and 1.4. > > http://cbbrowne.com/info/java.html This article is, frankly, a load of bovine excrement, and you should probably disregard all of it. It burns me up that so much anti-Java FUD abounds within the Open Source community. Anyone who, today, can write this about Java: "I'm not particularly a firm believer in Java. Actually, I think that to this point most of what has been said about it has been marketing droid snake-oil." ... clearly has no understanding whatsoever of the language and is in severe disconnect with the reality that Java/J2EE is an enormous success in the enterprise server arena. Its ONLY viable competitor today is dotNET. Then he goes on to expound common myths such as: "It seems fairly likely that Sun might mount legal challenges to anyone attempting to implement a system interoperable with JDK 1.2 as free software." This, again, is entirely false. First, there are already numerous non-Sun Java 1.2+ implementations (including closed-source ones) and none of them have been legally harassed. Secondly, IANAL, but it is my understanding that Sun has no legal ground whatsoever to prevent such software from being developed. There are no trade secrets here. All of the official API and JVM documentation can be viewed *without* having to agree to any license or non-disclosure agreement. The ONLY time you have to agree to the SCSL license is if you want access to the proprietary Sun source code. Open Source developers, thus, simply do not look at the Sun source code and instead write from scratch using the official documentation. The ONLY thing you cannot do is call your own clean-room Java implementation "Java" unless Sun has approved it -- which is because they hold the trademark. This is really of no consequence for our purposes. His discussion of J2EE is, again, severely lacking in understanding. "J2EE attempts to address the same kinds of areas that various Python Web frameworks" bzzz.. wrong. Java attempts to address far bigger needs than "web frameworks," which is all that Python has managed thus far. I'm seeing a trend of misunderstanding here.. I will finish my response to the previous email when I get a chance. I am doing more research into the specifics of EJB's and how they relate to implemention the distributed transactions, etc. Chris |
|
From: Jason M. <ma...@dm...> - 2004-03-29 04:32:10
|
Hi guys, Here is a web page that has some short but sweet overview info about Java. It has some info and links about the licensing concerns, and a little bit about J2EE. Be sure to check out sections 1.1, 1.2, and 1.4. http://cbbrowne.com/info/java.html -Jason |
|
From: Jason M. <ma...@dm...> - 2004-03-28 22:05:52
|
Hi Chris,
Great email! Thank you very much for writing that all up so well. I
think we're really making progress here! I have some comments and
questions for you below...
On Sat, 27 Mar 2004, Chris wrote:
>Both Java and Python are very good general purpose languages and it would
>be fully possible to write an equivalent to J2EE in Python.
I'm glad that we agree on that.
>Just a sidenote, I respect ESR's work, having read most of it myself,
>but his opinions are usually politically biased.
Fair enough, but also note that his bias tends to leave less room for
trouble later *in general* (may not apply in this case). In other words,
I think being biased towards Free software is a good bias to have. =)
>"Like Python, it cannot compete with C or C++ on raw execution speed"
>-- In reality, Java is now approaching the speed of compiled C++ code
>for many tasks. Python, on the other hand, is likely unable to ever
>reach speeds close to Java or C++ because of dynamic typing and other
>design choices that make it a good RAD tool. Today, Python is an
>order of magnitude slower on many tasks.
Personally, I'm not really worried about computational performance. IMHO,
ESR makes a great point in AoUP about hardware being cheap and people not,
and focusing on the most maintainable code. He makes a good argument for
the smallest amount of code possible (i.e. the highest level language
possible) because the number of bugs roughly corresponds to the amount of
code, regardless of the language used. All that being said, there are
plenty of "easy" ways to increase software run-time performance short of
using a lower-level language. Java is pretty high-level, but not as much
as Python.
>First of all, you overestimate the amount of control that Sun has over
>the Java scene. J2EE is not the only enterprise framework available
Ok, that's good to know. What are some of the other enterprise frameworks
available in the Java world?
>I think J2EE can be best described as a complete collection of cohesive
>tools that work well together for developing "enterprise-class"
>applications.
I think we're homing in on the target, but your definition sounds more
like a generic definition for "enterprise framework" than a definition of
J2EE. More on J2EE further below...
>So the question becomes: what exactly are "enterprise-class"
>applications, are we attempting to develop something that meets this
>criteria, and if so, what tools are available for completing our goal
>in a reasonable timeframe?
That's a good question to ask. Thanks for the writeup of "enterprise
class". I agree that it's probably important to make sure that whatever
road we head down doesn't negate any of those requirements, however I feel
quite strongly that we don't need to provide all of that on the first try.
In other words, we want to make all those requirements possible, but not
necessarily implemented right away. I think the open source model of
iterative development and throwing out things that don't work is a good
one. If we try to achieve perfection and feature completeness all up
front then we're setting ourselves up for disaster.
>So now that we have defined some criteria for what we consider to be
>an "enterprise application", we must ask whether this is something
>that we aim to develop.
Sure, I think that is definitely something to aim for, but see my previous
paragraph for my thoughts about how to get there.
>I have literally hundreds of ideas written down on how software (and
>technology in general) could be better tailored to church needs and many
>of these require modern enterprise-class architecture.
I'm really glad that you've done so much thinking about these problems and
the best way to solve them. I think it would be neat to get together in
person sometime - I'd love to hear more of what you have written down.
>With the criteria of an enterprise application in mind and the
>decision that enterprise-class architecture is needed, I look at the
>options:
>
>1.) Existing Python solutions, which provide NONE of the
>enterprise-class framework needed to do what I want. (And there is
>no sign that anything being developed will fulfill my needs in the
>future)
>
>2.) J2EE, which provides EVERYTHING that I need to start today
Now let's dig into what you wrote there a little more. Which parts of
J2EE excite you so much? There's quite a bit of what Sun calls "J2EE"
that Python and other languages do just fine. I want to find out exactly
what is so great about J2EE so we can know why it's such a good fit for
us. I'll take a stab at going through the J2EE technologies that are
talked about in Chapter 1 of the J2EE 1.4 Tutorial[0]
Components
----------
- Client
- J2EE clients are either a "web client" or Java application
- this part translates easily to a non-J2EE environment (need I say
more?)
- Web Components
- Servlets (aka CGI or server side scripts) - nothing special here
- Java Server Pages (JSP)
- mixing code & HTML like PHP & the various Python mechanisms (PSP,
etc)
- again, nothing special here
- Business Components
- Enterprise JavaBeans (EJB) - basically objects you can use remotely
with standardized interfaces (method names, etc)
- now we're getting more interesting, but other platforms can do
remote procedure calls & remotely callable objects
- 3 types of beans: Session, Entity, and Message-Driven
- Session beans handle a connection with a particular client
- nothing revolutionary sounding here
- Entity beans handle mapping program data into the database
- basically O-R mapping?
- Message-Driven beans seem kinda vague, not sure what they do
- Enterprise Information System Tier
- aka "a database" =)
Containers
----------
Their description is a little vague, but it sounds like they're
basically the code that actually talks XML-RPC, DNS, LDAP, PAM, etc.
As far as I can tell there's nothing too special here - other platforms
have libraries to talk those protocols for you.
Web Services
------------
Not a whole lot to say here. Python and other platforms can handle all
the web, XML, XML-RPC, SOAP, etc stuff just fine via their libraries.
J2EE 1.4 APIs
-------------
Now we get to the list of acronyms Sun has bunched up in their J2EE
diagrams:
- Enterprise JavaBeans - remotely callable objects
- Servlets - CGI
- Java Server Pages - PHP/PSP
- Java Message Service (JMS) - distributed communications
- not sure if this is special or what the analog is on other platforms
- Java Transaction API (JTA) - lets you couple operations as a single
transaction, but doesn't sound hugely interesting since the DBMS can
do that too (PostgreSQL can anyway)
- JavaMail API - email sending library - nothing special here
- JavaBeans Activation Framework - included because JavaMail uses it
- Java API for XML Processing (JAXP) - plenty of support for parsing XML
on other platforms
- Java API for XML-Based RPC (JAX-RPC) - XML-RPC and SOAP; nothing special
- SOAP with Attachments API for Java (SAAJ) - lower level API that JAX-RPC
uses; tutorial basically says to use JAX-RPC and not this
- Java API for XML Registries (JAXR) - Python has UDDI support
- J2EE Connector Architecture - connections to DBMSes; nothing special
- JDBC API - connections to DBMSes
- Java Naming and Directory Interface (JNDI) - standard API for resolving
names into things, i.e. DNS, LDAP, RMI objects, etc - sounds useful but
not necessary
- Java Authentication and Authorization Service (JAAS) - Pluggable
Authentication Modules (PAM); Python has PAM support too
- Simplified Systems Integration - not an API, but just a summary of why
J2EE is so great. =)
--- [End J2EE list] ---
Phew, that was pretty intense. =) So now, given all of the above, what
makes J2EE so special? Any thoughts? The only things that look
interesting to me are Enterprise JavaBeans and Containers, and those
mostly because I understand the least and they sound like the most
"enterprisey" (not just "web services" stuff). Please let me know if you
know exactly what EJB and Containers are.
Thanks for reading all this Chris, I'm looking forward to your response!
-Jason
[0] http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html
|
|
From: Chris <de...@op...> - 2004-03-28 00:01:24
|
On Friday 26 March 2004 4:21, Jason Maas wrote: > The point I'm trying to make is that the whole "Python vs. J2EE" > debate has nothing to do with the underlying language. I think > that anything possible in Java is just as possible with Python. I > don't think there is anything about J2EE that is inherant to Java > and could never be duplicated in any other language. Python *is* a > general purpose language, just like Java. You are certainly correct. Both Java and Python are very good general purpose languages and it would be fully possible to write an equivalent to J2EE in Python. The problem is that nobody has done this yet -- not even close. If we were to go the Python route, we would have to re-invent something along the lines of J2EE. Sure, this would be kinda fun, but we have nowhere near the time nor manpower nor experience to do it right. > Eric Raymond's descriptions of Python [1] and Java [2] in his > latest book, The Art of Unix Programming might be helpful reminders > of what we're talking about. Just a sidenote, I respect ESR's work, having read most of it myself, but his opinions are usually politically biased. ex.) He will tend to portray Python in a better light because it has Open Source roots whereas Java is only now entering the Open Source landscape. While I agree with his philosophy, this may be a case where pragmatism needs to be the deciding point. His discussion of Java in AoUP is also factually flawed and misguided. The following statements are misleading or untrue: "Like Python, it cannot compete with C or C++ on raw execution speed" -- In reality, Java is now approaching the speed of compiled C++ code for many tasks. Python, on the other hand, is likely unable to ever reach speeds close to Java or C++ because of dynamic typing and other design choices that make it a good RAD tool. Today, Python is an order of magnitude slower on many tasks. "Restrictions in the SCSL continue to hamper open-source implementations of Java 1.2 and their J2EE (Java 2 Enterprise Edition) specification. This compromises Java's original objective of universal portability." -- In reality, the Java and J2EE specifications/API docs are all open and there is nothing "hampering" Open Source implementations of Java 1.2+ or J2EE other than a lack of manpower in those respective OSS projects. The only thing not open is the original Sun source code, which is licensed under the SCSL license and cannot be viewed by those working on OSS implementations. "However, Java seems to have found a secure niche in the computing ecology, for servlets running within Web application servers." -- This statement greatly downplays Java's strengths and industry acceptance. Java is, in fact, the backbone of ALL enterprise application server platforms other than .NET. JBoss, IBM WebSphere, BEA WebLogic, and others all use Java. > What is J2EE really? We need a no-hype beginner's definition. I > read the first chapter of Sun's J2EE v1.4 Tutorial [0] and my best > guess so far for defining "J2EE" is "a set of standards and > APIs/libraries on top of Java 2". Nothing radical there that > couldn't be done using a different programming language. The open > source languages like Python tend to have many frameworks for doing > all sorts of things because there is no central Sun-like > organization mandating what the certified/licensed programmers must > do. First of all, you overestimate the amount of control that Sun has over the Java scene. J2EE is not the only enterprise framework available (although it is currently the best) and there is no mandate or certification or license defining what programmers can or cannot do with Java. Even JBoss's J2EE implementation strays slightly from being a "straight Sun" approach with some extensions like Aspect Oriented Programming. What is J2EE really? I agree that this is not usually clear, and yes, there is way too much hype/marketing to cut through. I think J2EE can be best described as a complete collection of cohesive tools that work well together for developing "enterprise-class" applications. So the question becomes: what exactly are "enterprise-class" applications, are we attempting to develop something that meets this criteria, and if so, what tools are available for completing our goal in a reasonable timeframe? First, lets discuss what being an "enterprise-class" n-tier application entails. Since this term is ultimately marketing-speak, we must go by the general industry consensus. An "enterprise-class" application requires: 1.) Scalability - If we need more performance, we can simply add more hardware at whatever tier is creating the bottleneck. This requires that all application components be fully modular and exportable such that our application can be distributed across many machines acting as if one. 2.) Reliability - Failover: if one machine dies, a backup can take its place or another in the chain can pull double-duty automatically while the other is repaired. This is increasingly important with the unreliability of inexpensive hardware commonly in use today. With n-tier distributed apps, it is even more important, in order to avoid single points of failure. If problems arise in the software itself, they can be repaired on the spot because the application components are hot-pluggable. 3.) Extensibility - We can easily customize or extend functionality and incorporate external data sources without having to re-write the core application or even take the application offline for maintenance. By utilizing web services, we can even extend our application to connect multiple campuses and/or share information resources with other organizations. 4.) Integrity - All operations upon persistent data stores are fully transactional, logged for auditing purposes, and capable of being rolled back at any point in the future should the need arise. Because our application is n-tier and distributed, the entire architecture must be designed from the ground up to support distributed transactions. Transactions must even be able to survive node failure and pick up where they left off once a backup is online. Furthermore, we must be able to wrap transactional functionality around even non-transactional data backends. Keep in mind that we are talking about application-wide transactions, not just SQL. 6.) Security - Just as with reliability, we cannot allow for single points of failure within the application. Think of it as layers of protection, as with firewalls and IDS. If one of our web hosts is compromised, this should not compromise the integrity of the whole application or expose all our data. And perhaps one other nicety, though certainly not required: 7.) Portability - The application can be taken "on the road" with a private copy of needed data and then synchronized whenever network access is available. This is perhaps the ultimate test of flexibility. So now that we have defined some criteria for what we consider to be an "enterprise application", we must ask whether this is something that we aim to develop. Your initial reaction may very likely be, "Whoa.. but churches and non-profits don't really need the same level of professionalism in software as Fortune 500 companies." That's what I used to believe. But I now say, "False. They have most of the same needs. Why should they be expected to use inferior solutions?!" In case you are unaware, many large churches and Christian organizations are already turning to very expensive solutions from IBM, Oracle, PeopleSoft, etc. Most other medium/large sized churchs and orgs are using off-the-shelf Church Management Software and business accounting software that is greatly inferior in design to enterprise-class solutions. This is simply because they cannot afford anything better. With Open Source, we should not be perpetuating the status quo; we should be raising the bar. If we do not, somebody else will, and churches worldwide will continue to spend billions on proprietary software -- most of it inferior to what is possible. InfoCentral, at this point, provides a solution that works well for small-medium churches who previously used a spreadsheet or crude "church software" to keep track of their membership. In hindsight, the choice of PHP was a poor one. It simply does not scale. My ultimate goal is to provide a complete, all-in-one solution for all church software needs -- not a patchwork of half-baked software hacked together or a simple intranet application for doing membership, fundraising, and reservations. I have literally hundreds of ideas written down on how software (and technology in general) could be better tailored to church needs and many of these require modern enterprise-class architecture. With the criteria of an enterprise application in mind and the decision that enterprise-class architecture is needed, I look at the options: 1.) Existing Python solutions, which provide NONE of the enterprise-class framework needed to do what I want. (And there is no sign that anything being developed will fulfill my needs in the future) 2.) J2EE, which provides EVERYTHING that I need to start today Frankly, it's a no-brainer in my mind. > I'm just worried that the complexity of Java and J2EE will really > slow us down both up front and in the long run, plus I'm not > convinced that we need that complexity. Python seems to be breath > of fresh air compared to Java, is just as capable as a language, > and it's open source status is not up in the air. The complexity of J2EE will, in fact, slow us down up front. However, it is currently the only path which takes us where we need to go. This is not because Java itself is "harder" than Python; it is because the solution we should be aiming for is more ambitious. Now a *really* slow path would be re-inventing J2EE in Python and *then* developing our application. Java's "open source status" is not up in the air. The Open Source implementations are simply incomplete, though they are certainly progressing. If you want a fully Open Source Java sooner, you can always donate to the Kaffe and GNU ClassPath projects and encourage others to do the same. > If we could use > the J2EE spec and do all the development we wanted to in Python > using Jython I'd be a little less reluctant. I did a quick Google > on using Jython with JBoss and it sounds like other people are > trying it with some success. It's fully possible that we could use Jython for some things, but it still wouldn't remove the need for Java and J2EE. I would have to do more research in this area.. > I do shudder about JBoss describing > their application server as "lightweight" with a 35MB download of > source code though. A mere 35MB is trivial today and this is very lightweight considering all that JBoss does. Most commercial application servers weigh in at hundreds of megs and have much higher hardware requirements as well. Chris |
|
From: Jason M. <ma...@dm...> - 2004-03-26 21:22:09
|
Hi Chris, On Wed, 24 Mar 2004, Chris wrote: >Again, this whole discussion comes back to a decision of "best tool >for the job." Python is a great language, but I don't feel it is the >best tool for what I intend to accomplish with InfoCentral. The point I'm trying to make is that the whole "Python vs. J2EE" debate has nothing to do with the underlying language. I think that anything possible in Java is just as possible with Python. I don't think there is anything about J2EE that is inherant to Java and could never be duplicated in any other language. Python *is* a general purpose language, just like Java. Eric Raymond's descriptions of Python [1] and Java [2] in his latest book, The Art of Unix Programming might be helpful reminders of what we're talking about. What is J2EE really? We need a no-hype beginner's definition. I read the first chapter of Sun's J2EE v1.4 Tutorial [0] and my best guess so far for defining "J2EE" is "a set of standards and APIs/libraries on top of Java 2". Nothing radical there that couldn't be done using a different programming language. The open source languages like Python tend to have many frameworks for doing all sorts of things because there is no central Sun-like organization mandating what the certified/licensed programmers must do. I'm just worried that the complexity of Java and J2EE will really slow us down both up front and in the long run, plus I'm not convinced that we need that complexity. Python seems to be breath of fresh air compared to Java, is just as capable as a language, and it's open source status is not up in the air. If we could use the J2EE spec and do all the development we wanted to in Python using Jython I'd be a little less reluctant. I did a quick Google on using Jython with JBoss and it sounds like other people are trying it with some success. I do shudder about JBoss describing their application server as "lightweight" with a 35MB download of source code though. [0] http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html [1] http://www.catb.org/~esr/writings/taoup/html/ch14s04.html#python_language [2] http://www.catb.org/~esr/writings/taoup/html/ch14s04.html#java Jason |
