So in saying that as a alternative to EJB with CMP, Hibernate is the current de-facto standard for persistence in the Java developer and architecture community. This is due to the following reasons:
#1- It is a freely available open source product, and this satisfies most budgetary constraints. There is a supported licensed version from JBoss Inc as their JBoss Enterprise Middleware System suite uses Hibernate as a persistence layer. It is supported 24x7 by JBoss Inc. if purchased, and the firm provides training for Java developers as well. This bodes well for companies whom do not have a comprehensive open-source mandate in effect.
#2- Hibernate is the closest product to a reference implementation of the EJB 3.0/JSR-220 persistence standardization effort. JSR-220 is the Sun and Java community effort primarily concerned with improving the EJB architecture, by reducing its complexity for developers. Currently two Hibernate employees sit on the International voting panel for this JSR effort, considering the likes of IBM, SAP and IBM are involved, this speaks volumes for Hibernate?s acceptance in the persistence community, and for their continuing support of EJB. Thanks for helping to prove my point by mentioning Hibernate....
Sure, Hibernate can be used without the new EJB3 persistence APIs, and yes, it is still more powerful than current market alternatives without it, but having said that, most developers love Hibernate since it persists most JavaBeans with no code changes to the existing beans.
I don't really understand these evangalistic arguments anyways. For you, you might not be needing these large-scale development tools and frameworks, or you might have in-house tools that fit your requirements. I regard even obscure technologies as having a place, and this talk of EJB doesn't even come close to being obscure. Touting a technology as dead or alive reveals an inflexibility that may not be in your development efforts best interests.
Sincerely,
Frank Krul
Frank
Lets be honest. I'm a guy that used
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
| Web site design development | Computer software development | Software design and development |
| Macromedia flex | Software development best practice |
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.
