From: Devdas Bhagat devdas@dvb.homelinux.org
IMHO, J2EE and LAMP differ largely in scalability and complexity. J2EE is more targeted towards complex applications, while LAMP is more suitable for small - medium scale web applications.
Dunno. Linux, Apache, Perl/Python, PostgreSQL *scale*. You do know that you can do OO development with both Perl and Python, right? Of course, doing proper, scalable design helps in any case.
Scalability is not just about programming languages or handling N requests per second. It's also got to do with the facilities offered by the platform to handle application level complexity - the complexity that your application requires to support. Note that my comment stressed more on complexity.
How well can your chosen platform allow the programmers to code as close as possible to the business logic as compared to coding the minutae like concurrency control or transaction management or messaging is what it's all about.
Another little thing that might get ignored is that a P/L is not the /only/ deciding factor in a platform. So, indeed, you can have a highly scalable distributed computing platform developed entirely in Perl. (I don't know if we already do :p)
Personally, I am also planning to look into C++ with XML as a platform for enterprise applications and web services. There are some really
Buzzword Compliant Programming?
LOL! IMHO, C++ is not a buzzword and XML is more than just a buzzword. If this combo looks like buzzword compliant programming, that's a favorable by-product :)
capable application development frameworks like ACE available for it. Generally, stuff that's available in J2EE is also available in C++. It's just that the former gets noticed since there's no c++.bigcorp.com. Oh, but my opinion may be biased due to my perennial rant against Java, the platform. ;)
Are the libraries available in C++ for enterprise applications as extensive as J2EE? I think most people choose J2EE because of the huge array of libraries/components available, which they can leverage right away.
Till date, I haven't encountered anything in the Java world that doesn't have a functional equivalent in the C++ world. Of course it could mean that I haven't encountered enough ;)
AFA reasons for choosing Java are concerned, I guess a pretty strong factor is also the availability of programmers for it and the collective reference to the P/L, the platforms and the libraries as "Java", which makes it look like something really big.
Another reason in favour of Java is automatic garbage collection. This makes it easier to create more robust applications. Does C++ have something equivalent.
For those of us who know how to manage memory, garbage collection isn't much of a gain. When we wish to avoid it, we use languages which do it for us without the memory hogging and performance thrashing JVM.
GC is not all that bad actually. Once you get used to programming with it, it feels a little arcane doing your own memory management. Good news is that there are GC libraries available for C++ also. Plus, you get a set of choices to make while optimizing your program, instead of just an always-on-for-everything GC. Here's some nice reading: http://www.iecc.com/gclist/GC-faq.html
I have used Java for quite some time and have found it to be a reasonably good platform to use. However I have never used C++ to build enterprise level applications, so I am not familiar with it's strenghts.
C++ can be a scalpel in the hands of a reasonably competent programmer. Java makes some things easy, but the things that aren't really supported by Java are a pain.
That apart, Java also confines you to a very restricted environment. Either there's a library that allows you to talk to the world outside the JVM or you're stuck.
I would say J2EE and LAMP both have great features and good developer bases to utilize these features. The real issue is not what architecture is best, but what architecture will help achieve organisational goals while maintaining the desired level of security, robustness, and flexibility. It is also important to keep in mind that these two architectires were developed with different end-users in mind.
Sun Micro, who used to service high-end clientele, originally developed Java (I'm not talking about Oak) to create a new market for them to enter into: application development tools, server software, licensing fees, training fees, certification fees, etc. The LAMP architecture's projects on the other hand rose from the needs of SMEs and small-time developers unable to pay high amounts for adopting technology architectures and remaining profitable at the same time (very short story version). Evolving as seperate projects, each intended to offer freedom from the limitations of commercial softwares that also depended on the economic viability of individual developer companies.
Currently, the situation is that large corporations, with legacy purchases, succumbing to FUD propoganda by large commercial companies, opt for what they (mistakenly) call "supported" (commercial) software. On the other hand, you have smaller, newer companies unburdened by legacy purchases, and with a better understanding of Free Software, looking at this as an attractive option to increase short-term, and maybe long-term profitability. I am not counting development houses here as they generally opt for the technology of their major clients.
Hence, as we can see from the facts above, at the end of the day the choice of J2EE or LAMP depends on what architectures companies are willing to pay for and sustain, and NOT what consultants or even their own IT/IS departments recommend.
Clinton Goveas http://www.clintongoveas.com
------- Open Source Knowledge Base - http://os.clintongoveas.com Securely Distribute Your e-Products - http://ods.clintongoveas.com
-
Clinton Goveas -
Tahir Hashmi