Lets be honest. I'm a guy that used to the Open Source Frameworks because the guys developing them are honest. They want only money for support, while the monsters that vote for EJB want to sell their IDEs and their application servers that supports that crappy heavy technology.
It is not honest to tell that
>By far the current most popular form of persistence frameworks is the EJB 2.0 standard
look at the any recruiting site to see what technologies are most wanted to be familiar by Java developers. EJB has about 15% and as far as I know that 15% are support of the old projects. Actually now the only thing that remains from J2EE is servlets and JMS for everything else we have Spring, Hibernate and other frameworks.
Look at the any Java community site, EJB is dead. EJB2.0 is the worst technology I've ever known and even Sun now recognize it. And however EJB 3.0 is pretty like Hibernate I'd better use Hibernate with Spring than it. The same features but I can run it on Tomcat that is much liter than any EJB3.0 compliant app server.
Spring Hibernate and AOP makes EJB dead!!! And great thanx to them. I do not need XDoclet any more, I can run unittests without Cactus I can deploy my application anywhere I do not need crappy EJB deployment descriptors, and I'm happy with it.
--
Best Regards,
Mykola
On 11/21/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I think we all have to realize that all of our declarations on this topic are relative to our own experiences. That being said, if you use simple procedural JSPs, and servlets to expose DB backends using JDBC, then you might say EJB is dead. On the other side of the coin, if you do large scale, enterprise wide development, EJB is a life saver. Take persistence frameworks as an example...what are the alternatives outside of proprietary, non-standard COTS products?By far the current most popular form of persistence frameworks is the EJB 2.0 standard. This allows Container Managed Persistence, in which the application server manages the persistence for the developers, allowing them to concentrate on coding business logic instead of implementation specifics. Prior to EJB 2.0, the specification mandated remote interfaces and had no way to express relationships between objects. Both of these problems harmed performance, but they were fixed in EJB 2.0. Today CMP ships with all J2EE EJB 2.0 compliant application servers, thus it has a huge advantage over the rest of the marketplace due to the ubiquitous nature of the platform.
Truthfully, there are many analysts whom (after reviewing the initial CMP and EJB spec) developed their own forms of persistence frameworks, and 2.0 did little to persuade them that things had changed radically for them to migrate away from their ingrained technologies.
Thankfully the World of IT developers realized the deficiencies of previous persistence models and/or the hard sell in introducing a proprietary in house persistence platform to (rightfully) wary IT management groups at conservative publicly traded firms. What is required is an official java standard for persistence, and that is exactly what JSR 220 a part of the Java community process for standardization is. The Java consortium feels that by getting the entire Java community behind one standard Java persistence API, they will simplify the now-confusing, expensive and risky development of J2EE and J2SE applications using data persistence. During the specification member voting in August of this year, all present firms (Apple, Apache, IBM, BEA, JBOSS, HP, SAP, Oracle et all) voted on the specification with such epiphanic comments such as:
?We believe JSR-220 will have great impact on the Java enterprise eco-system and will give productivity back to the developers.? ?JBOSS Inc.
This new architecture provides a standard way to transparently persist plain Java objects. It is designed to work in multiple tiers of enterprise architecture, including J2SE, Web tier, and Application Servers, allowing it to be used for both the Web-based RFP and client-side java apps.
This standard is an amalgamation of both CMP, which is for persisting distributed components built specifically to the entity bean component API, and JDO, which is geared towards local, rich object models not tied to any particular API. Developers can choose between these technologies by evaluating their requirements (persistent components or persistent objects).
With both the freely available open-source persistence, and the maturing of the common, and now ubiquitous EJB model, it is highly suggested that EJB is in for its' glory days. As this new SUN EJB 3.0 persistence framework is an extension of both EJB 2.0 CMP and the existing JDO API, the adoption of this new technology is an easy one for most Java developers working in common J2EE services architectures, for the initial exposure has already occurred.
My opinion is that EJB is far from dead, one only has to look at the voting members for the JSR....all the big players are there. With Java being one important player in granting our flex apps the data it exposes, these questions are only going to become more important for FLEX teams.
Frank Krul
Senior Consultant
Keane Canada
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
YAHOO! GROUPS LINKS
- Visit your group "flexcoders" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
