Jon Wetherbee

author
+ Follow
since Oct 05, 2006
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jon Wetherbee

JDeveloper lets you generate JPA entities from database tables. It looks for database foreign key constraints between tables and reverse engineers entity relationships wherever it finds them. If you don't happen to use formal constraints on your tables, you can use the JDeveloper JPA mapping tools to add, or tweak, relationships or other ordinary fields on your entities.

JDeveloper also lets you build up 'offline' database objects within the IDE, so you can edit your table definitions as you build your entities, and then generate SQL DDL for your offline schema into a live database connection, optionally replacing existing objects for iterative development.

Also note that in JDev 11 (early releases are available, final release is forthcoming), you can choose to store your edited mappings in either XML or annotations.
(Posted by Jon and Raghu, who had the pleasure of being guest authors a few months ago, for the release of our book 'Beginning EJB 3 Application Development: From Novice to Professional' [Apress, 2006])

Congratulations to Debu, Reza, and Derek on their contribution to the body of literature on EJB 3! As we can attest, writing a book on this significant and deep topic is no mean feat!

We thought it was worth mentioning that we have done extensive work in testing EJB 3 performance since its inception in the JCP. You can check out a detailed article that we published in JDJ that compares the performance of commonly used designed patterns in EJB 2.x and EJB 3.0, "The Performance of EJB 3.0 - Does Simplicity and Power Come at a Price?"

http://java.sys-con.com/read/131767.htm

In our book "Beginning EJB 3...", we have once again compared a specific use of inheritance hierarchies in JPA, and the article detailing the comparision is published in JDJ "Inheritance Hierarchies in JPA -- Understanding and comparing inheritance hierarchies in Java Persistence API."

http://java.sys-con.com/read/286901.htm

Our book goes into the performance methodology that can be used for real-world applications and details the steps on how to set up performance tests and how to compare the tests using the open source tool kit Grinder.

While the above may sound like shameless plug for our book, we thought you would find it relevant...

Thanks and best regards,
Jon & Raghu
Hi Alessandro-
I assume your tutorial covered J2ee 1.4, which defines EJB 2.1. In this version of EJB, Entity beans come in two types -- container-managed persistence (CMP) and bean-managed persistence (BMP). Are these the two types you are contemplating? If so, CMP beans let you define the object/relational (O/R) mapping metadata in XML, whereas BMP beans do not, and require you to provide your own persistence layer, commonly using directly JDBC calls.

In the latest version of EJB, 3.0, which is defined in Java EE 5, entity beans have been replaced by simple plain old Java object (POJO) entity classes. This new entity specification is defined by the Java Persistence API (JPA), and is widely seen as a great improvement over the EJB 2.1 and earlier entity bean model. I mention this because if you are new to EJB, I suggest you jump to EJB 3.0 and JPA entities instead of developing with EJB 2.1 entity beans.

Most commercial vendors now provide, or will provide shortly, production servers that support Java EE 5, which includes EJB 3.0 and JPA 1.0. Of course, if you are currently required to use a J2ee 1.4 server, then you can shelve away this knowledge for the future...

Regards,
Jon

P.S. For more info on EJB 3.0 and JPA 1.0, you may enjoy:
http://www.apress.com/book/bookDisplay.html?bID=10129
Hi Amit-
Actually, if you are using annotations with EJB 3.0 (note that you can use either annotations or ejb-jar.xml) the things you mention *would* change.

* Transactions
If you prefer annotations (and many people do), you could specify transaction attributes for the bean, or for any specific method, using the @TransactionAttribute annotation.

* Exceptions
In EJB 3.0, you no longer need to throw java.rmi.RemoteException from methods declared on your remote interface.

*Security
Security roles and method permissions also may be specified using annotations.

The main thing that *doesn't* change is the actual business logic in your business methods. If you accept the default transaction and security settings for your session bean, all you are left with to code is a simple class that is annotated @Stateless or @Stateful and contains ordinary methods for your business logic.

Looking beyond the defaults goes beyond the scope of this reply, but there is much written on the topic.

Regards,
Jon

http://www.amazon.com/Beginning-EJB-Application-Development-Professional/dp/1590596714/sr=11-1/qid=1162493716/ref=sr_11_1/002-0255731-2231223
Many thanks to all of you who participated, and congratulations to the winners of our book. We hope you enjoy reading it, and please post a review somewhere if you can find the time to do this. Also, please post any errata or other comments you have to the Apress web site.

I really enjoyed answering, and debating, the many insightful (and challenging) questions on this forum, and have felt very welcome in this civic-minded community. Mark, I think the spirit of this forum emanates largely from its moderator, so well done.

Regards,
Jon
Hi Samba-
Volumes have been written on this subject, and for every point made on the subject, there are three bloggers waiting in the wings with a counter argument.

I have already expressed my thoughts on the value of standards, but as a further point, I will say that if you like Spring, you could frame the issue not as "What about EJB3 vs. Spring" but "What about EJB3 *and* Spring". Spring is a perfectly good light-weight framework, and EJB3 has implicitly endorsed it by incorporating some of its core concepts. However, there are legitimate concerns about Spring's scalability, and it doesn't offer remoting support, something that is built into EJB3. These issues can be addressed, in cases, by wrapping Spring in EJB3, to take advantage of the EJB3 container's built-in services. The EJB container, and its surrounding Java EE server, in the context of an vendor-specific application server, offer a wide range of enterprise features that justify their use, particularly for large-scale deployments.

Beyond that, I'll leave this issue to other posters, or the legions of bloggers that are a google search away...

Regards,
Jon
Hi Jaikiran-
There is nothing preventing you from using Java inheritance when implementing your session beans, or your business interfaces. I haven't tried it, but if you were to have one class annotated @Stateless, say, extend another class annotated @Stateful (or @Stateless!), I think they would get deployed as separate session beans. For the subclass session bean, the @Stateful/@Stateless annotation on its base class would be ignored, and it would simply treat it as an ordinary base class.

Since there is no notion of persistent state, only session state, you don't run into issues with polymorphism, or in this case, observing session bean behavior through the super class that is attributed to its session bean meta data.

I think what JigaR was pointing out is that, in general, inheritance is much more interesting in the JPA realm, where you can choose from several built-in inheritance mapping strategies, and you can have polymorphic queries, relationships, etc.

Regards,
Jon
Hi All-

(from the related EJB3 versus Spring thread

I posted my general thoughts on this in this thread. As a further comment, I'll say that it is to the JSR-220 expert group's credit that it is incorporating technologies such as Spring/TopLink/Hibernate into the EJB 3 spec and turning them into standards. I would expect further advances in these areas, and in the "next" hot areas, to be incorporated into the spec in the future.

Regards,
Jon
Hi Sudd-
Yes, the question of Spring vs. EJB 3 is one I wish we had addressed head-on in the book. Due to various constraints, we could not address everything -- we'll save this topic for the next edition .

I posted my general thoughts on this in this thread. As a further comment, I'll say that it is to the JSR-220 expert group's credit that it is incorporating technologies such as Spring/TopLink/Hibernate into the EJB 3 spec and turning them into standards. I would expect further advances in these areas, and in the "next" hot areas, to be incorporated into the spec in the future.

Regarding patterns and best practices, this is a book primarly about learning and understanding the EJB 3 technology so you can decide how to put it to use. We don't emphasize patterns per se, and we try to stay agnostic to controversial topics in general, such as annotations vs. XML. We try to present the information you need to make your own decision on this type of issue.

Throughout the book we discuss choices you can make depending on the needs of your particular application. For instance, the discussion of entity inheritance covers a number of considerations based on how you plan to use your entities, how they might evolve over time, and so on. We also explain and provide examples of the session facade pattern, id generator and optimistic locking usage, transaction management, and many others. And of course, the MVC pattern is assumed throughout our design discussions.

Regards,
Jon
Hi Bruno-
Well, since you asked... . Raghu and I are on this forum this week to help answer questions about EJB 3 in general, and about the book we just wrote in specific. It's entitled Beginning EJB 3 Application Development: From Novice to Professional, and it was just published a few weeks ago.

Here's a comment I made in an earlier post that addresses the approach we take in this book:

I agree with Mark that the EJB 3 spec is very well written, and that it is written for a broad audience that includes app server providers (EJB container implementors) as well as EJB developers. By necessity the spec covers every intricate detail that can be specified. We aim our book squarely at the the EJB (and JPA) developer who is coming upon EJB 3 and looking for a convenient on-ramp to the techology. We elaborate on the main areas of the spec, while filtering out a lot of the advanced details, and reduce it to the most important concepts we think most EJB developers will need to get started.

Part of the trouble with a very broad technology like EJB is there is a lot of material to cover before you can see the trees for the forest. It is very difficult to jump into the advanced details of EJB and JPA before you have a good understanding of the most important concepts. Instead of wading into these advanced concepts, in many places we point readers to the appropriate area of the spec if they are interested in more depth. This way we are able to cover a lot of topics and keep the pace moving forward, without getting bogged down in the many advanced complexities that are covered in the spec documents.



Hope this helps.

Regards,
Jon
Hi Mark-
Despite my undeniable bias , I would recommend Oracle's JDeveloper IDE. It bundles OC4J, which is the pure Java EE portion of Oracle's iAS application server, so you have an integrated package for developing, deploying, testing, and debugging your Java EE 5 applications.

JDev 10.1.3.1 just went public with full support for the final release of the EJB 3 spec, and you can download it for free.

Regards,
Jon
Hi Jaikiran-
A Home (and/or LocalHome) interface is still required if you need to initialize the stateful session bean with argument data upon creation. It is optional if you don't need to initialize the bean, or if it is okay to follow up the instantiation with an explicit initialization method call, through the business interface (beware of this route, if it is essential that this method be called before any other business method on the session bean).

To use a Home or LocalHome interface, you can either continue to use the EJB 2.x style ejbCreate(a, b) method, if this was an EJB 2.x bean, or you can define your own initialization method with params that match your [Local]Home.create(a, b) method, and annotate it @Init (or define it using an init-method entry in ejb-jar.xml).

Regards,
Jon
Hi Jaikiran-
Good question. I don't know if the reason for this is spelled out in the spec, but I believe the reason why you can't collapse @Local and @Remote behavior onto the same interface is this would confuse the implicit lookup semantics. Remote interfaces pass objects by value, whereas Local interfaces pass by reference, so the EJB container needs to know which one it's dealing with when it serves up a session bean to a client. When injecting an EJB using @EJB injection (or the XML equivalent), the container determines, from the interface specified by the lookup, which way to go. If the interface is ambiguously declared as both @Local and @Remote, it wouldn't be able figure this out, so this is illegal.

Regards,
Jon
Hi Jeanne-
This really is an implementation detail specific to each vendor. In EJB 3, as in earlier releases, session beans with remote interfaces require remoting code (RMI/IIOP stubs/skeletons), but this can be handled through dynamic proxies. There is certainly no requirement for explicitly generated stub/skeleton classes.

Remote EJB 2.x entity beans had the same issue, but none of this applies to JPA entities, since they are POJOs and not remotable components. They can be serialized and passed between VMs (e.g. application tiers), but do not support the type of remote access that would require stub/skeleton code.

Regards,
Jon
Hi John-
One more thing. As far as migrating your servlet/JDBC code, the JPA makes this type of thing very convenient. Your servlet, and even your forms, can instantiate and interact with JPA entities directly, through the EntityManager API. Moving to JPA entities provides a much cleaner interaction between your web and your persistence tiers.

Regards,
Jon