Using POJOs with JDX™ OR-Mapper Instead of EJB Entity Beans with CMP

Two recent computer engineering graduates from San Jose State University have discovered a simpler approach to building pet stores that sell fast. Rajini Raju and Chaya Sudindrakumar, both from the class of 2003, have re-architected the Java Pet Store application by using Software Tree’s JDX data integration technology that removes the complexity out of Java/database programming. The resulting application provides more flexibility and superb performance.

ABSTRACT:
The Java Pet Store represents a typical J2EE e-commerce application, presenting views of products and services for sale. Pet Store calls upon several distributed components (EJB session beans), whose role is to interact with the data layer implemented using EJB components (entity beans) and CMP (Container Managed Persistence). Entity EJBs are pretty heavyweight and hard to use. This report describes how Entity EJBs can be replaced with POJOs (Plain Old Java Objects) and a lightweight Object-Relational Mapping (OR-Mapping) technology provided by JDX product from Software Tree to act as the persistence layer. In addition to greatly simplifying the architecture, this approach also seems to provide substantial performance improvements over the original implementation.
 
Full Press Release
 
FREE Report and More Details ....

Damodar Periwal
Software Tree, Inc.
Simplify Data Integration

Editorial: The TMC petstore case studies did significant benchmarking, so it would be interesting to see what the *real* difference is between this POJO version.

Can you compare the relative strengths of JDX's CMP-less petstore versus the slew of other POJO & ORM based petstores including:

xPetstore - http://xpetstore.sourceforge.net/
jPetstore - http://www.ibatis.com/jpetstore/jpetstore.html
Spring's PetClininc - http://www.springframework.org/webapps/petclinic/html/petclinic.html

I'm also interested in hearing why you decided to charge $99.95 for the source code to this simpler approach you've discovered, when I can get the source for the above mentioned stores for free.

The goal of this project was to replace entity beans with POJOs. Rest of the architecture includiing the use of session beans was kept in place. For example, it is not a servlet based redisign.

A detailed report is alredy provided FREE. of charge. We think that the nominal charge for the full implementation. will be worth it for those who are really interested in the nitty-gritty details.

Thanks,

-- Damodar

Sorry for the typos in the last message. Reposting.

The goal of this project was to replace entity beans with POJOs. Rest of the architecture including the use of session beans was kept in place. For example, it is not a servlet based redesign.

A detailed report is already provided FREE of charge. We think that the nominal charge for the full implementation will be worth it for those who are really interested in the nitty-gritty details.

Thanks,

-- Damodar

Awhile ago, software tree posted similar comments about their STORM benchmark.

https://theserverside.com/news/thread.tss?thread_id=22196

I conducted some research into the matter using Jaxor. Jaxor proved to be signficantly faster in my environment. Software Tree could not refute these claims except to say that I should try the "newer version". As always, these type of benchmarks don't prove much of anything.

http://jaxor.sourceforge.net/?q=jdx

Gavin King also posted his findings on the prior benchmark.

http://www.hibernate.org/157.html

With this benchmark, I would have to fork over some cash just to see the source, so I won't be taking the time to take a look.

Regards,

Mike Rettig
Jaxor Developer

STORM benchmark code (including all the documentation and scripts) comes FREE with the FREE evaluation version of JDX.

I believe you when you say that JAXOR ran faster in your environment. I think it may be faster as it does not use reflection like JDX does. Still you may want to try the newer version of JDX if you get a chance. Query performance of JDX has improved significantly since then.

Thanks,

-- Damodar

xpetstore is based on hibernate 1.x so that should be pretty comparable

according to this thread

https://www.theserverside.com/news/thread.tss?thread_id=22196

jdx doesn't outperform hibernate in most situations, despite software tree's attempts to spread FUD that claims the contrary

so performance realy shouldn't vary much, especially since hibernate now supports caching, Neighter should it be more difficult to build, afterall JDX is just another or mapper.

oh and petclinic isn't the petstore app it's a seperate example.

There is no need to rely on FUDs by different vendors. STORM is an open benchmark. It is easy to configure and run. You are welcome to download and run it in your own environment. I believe that will help you draw right conclusions.

Thanks for the clarification on petclinic.

-- Damodar

There is no need to rely on FUDs by different vendors.

It is true, any benchmark I have ever saw is a FUD.
I will be very surprised if this benchmark shows authors product is not the best.

There is no need to rely on FUDs by different vendors.

It is true, any benchmark I have ever saw is a FUD. I will be very surprised if this benchmark shows authors product is not the best.

I can appreciate your skepticism. With STORM though, you get to see the full source code and scripts. Also, you get to run the tests in your own environment with your own set up of cpu, memory, databases, JDBC drivers etc. There is nothing to hide. And you may well be surprised to find your favorite product giving better results than JDX:) At least that should make you feel more comfy with your choice.

Of course, it may be best to develop your own benchmarks, which reflect the true nature of your application. STORM can give you a quick initial read nonetheless.

Regards,

-- Damodar

At least that should make you feel more comfy with your choice.Of course, it may be best to develop your own benchmarks, which reflect the true nature of your application. STORM can give you a quick initial read nonetheless.Regards,-- Damodar

I developed a few benchmarks myslf at home and I fount it is possible to "prove" eveything using this way, It was not about persistence, I have tried to test "better" algorythms for JAVA. I hope your benchmarks are better, but most performance problems in persistence user produces himself (it is about myself too), I think it is better to provide some hooks for debuging/tracing than to optimize some trivial function in library.

I believe that optimizations like using connection pools, minimizing the number of database trips, using prepared statements, short code paths etc in an OR-Mapping framework do make significant improvements in performance. Even if you are hand-coding JDBC, these are worthwhile techniques to employ. Then there are important database side optimizations like proper index creations to improve lookups.

JDX provides multiple levels of debug/tracing support including logging of all SQL statements. Please try JDX/STORM and let us know what you think.

-- Damodar

I believe that optimizations like using connection pools, minimizing the number of database trips, using prepared statements, short code paths etc in an OR-Mapping framework do make significant improvements in performance. Even if you are hand-coding JDBC, these are worthwhile techniques to employ.

Yes, lazy loading, "N+1" was a problem few yers ago, but I am sure JDX and most OR-Mapping frameworks solve it. I think you will agree, it is better to document
important fetures than a benchmark.

Then there are important database side optimizations like proper index creations to improve lookups.JDX provides multiple levels of debug/tracing support including logging of all SQL statements.

SQL tracing is very important, but I can enable it on server or to plugg wrapper
for JDBC driver. Statistics collection and logging is more important and it is very important to relate application statistics (cache, blocking ) with OS (sar) and DB statistics (query plans and index usage). Probably it is better to use some generic tool and looks like there is a good product to solve this problem too.
I need to learn more about distributed cache and concurency control used in this
cache, I think most O/R tools are equal except this feature.
BTW have you tried to benchmark distributed object cache vs DB instance per server and local materialized views for query cache. I hope cache is more performant, but results must be more interesting than O/R vs O/R and this benchmark is not so trivial, if possible to compare this kind of things.

I think you will agree, it is better to document important fetures than a benchmark.

It depends upon different needs of different people/projects. Sometimes ease-of-use or flexibility may be more important than just a list of features or performance numbers. Since a comment was made on the STORM benchmark in this thread, some postings talked about that. If you are interested in learning about JDX features, please check this link.

As mentioned before, the goal of this remodeling project was to see the feasibility of replacing entity beans with POJOs and using JDX OR-Mapper for persistence. Although the performance numbers are interesting, this was not intended to be a benchmarking project.

I agree that there are many different ways of collecting and correlating all sorts of statistics. That data can be quite useful, especially for fine-tuning of mission-critical and high-end applications. However, if you build your system with well-defined, flexible, and optimized components, the fine-tuning exercise will most likely go much more smoothly than in the situation where you had to develop and cobble together a lot of code pieces in a hurry.

Seems like you have some ideas about creating comprehensive benchmark programs including performance/interactions of distributed caches, databases, and operating systems. My personal opinion is that the appeal and usefulness of a benchmark is inversely proportional to the number of components and controlling parameters used in the benchmark.

Regards,

-- Damodar

Yes, I think benchmark is usefull if it helps to tune something (helps to tune JVM parameters, FS cache and swap, DB cache and indexes, finds application problems like blocking or recommends to upgrade hardware ). Benchmarks I do at home are used not to select some product, but to improve my current deployment.
 If benchmark is a marketing trick to promote some product then documentation about performance tuning and source code for debuging is more usefull than this benchmark. Any technology is more mature than my code at development time and it is more impoertant how it helps to improve my code. If you can sell product and heve users than I can trust this product without benchmark (google can help to find about it too).

You may find the following links with some customer comments about JDX useful:

Testimonials

Case Studies

(Reposting with better formatting)

Hello,

Based on our high-level review of JPetStore and xPetstore, here is the summary of the goals and the component architecture of different Pet Store projects:

JPetStore

Goal:To develop a fully functional web application based on iBATIS open source persistence layer products
WebTier: JSP, Struts
Business Logic: POJOs
Business Object:POJOs
Persistence: SQL Maps, DAO
URL: http://www.ibatis.com/jpetstore/jpetstore.html

xPetStore (EJB Implementation)

Goal: To provide a pure EJB solution based on JSP, Struts, Sitemesh, EJB 2.0 and CMP 2.0
WebTier: JSP,Sitemesh,Struts
Business Logic: Session Beans
Business Object: Entity Beans
Persistence: CMP
URL: http://xpetstore.sourceforge.net/xpetstore_ejb.html

xPetStore (Servlet Implementation)

Goal: To provide a Servlet based solution using POJOs and Hibernate as persistence Framework
WebTier: Velocity, Sitemesh, Webwork
Business Logic: Webwork
Business Object: POJOs
Persistence: Hibernate OR-Mapper
URL: http://xpetstore.sourceforge.net/xpetstore_servlet.html

JDXPetStore

Goal: Replace Entity Beans With POJOs; use JDX OR-Mapper for persistence of POJOs
WebTier: JSP,Servlets
Business Logic: Session Beans
Business Object: POJOs
Persistence: JDX OR-Mapper
URL: http://www.softwaretree.com/products/jdx/JDXPetStore.htm

Regards,

Chaya & Rajini

<<
xPetStore (Servlet Implementation)
Goal: To provide a Servlet based solution using POJOs and Hibernate as persistence Framework
WebTier: Velocity, Sitemesh, Webwork
Business Logic: Webwork
Business Object: POJOs
Persistence: Hibernate OR-Mapper
URL: http://xpetstore.sourceforge.net/xpetstore_servlet.html
>>
Are u sure they are putting business logic in Webwork components.

<http://xpetstore.sourceforge.net/xpetstore_servlet.html>>Are u sure they are putting business logic in Webwork components.

Hello,
 
Please check the following URL for clarification

http://xpetstore.sourceforge.net/specifications.html

It is given that in xPetstore,"The Model and Controller implemented with Webwork. All the business logic is implemented at this level."

Thanks,
Chaya & Rajini

<html>
<body>
Hello,<br>

Based on our high-level review of JPetStore and xPetstore, here is the summary of the goals and the

component architecture of different Pet Store projects:<br><br>

JPetStore<br><br>
 
Goal:To develop a fully functional web application based on iBATIS open source persistence layer products<br>
WebTier: JSP, Struts<br>
Business Logic: POJOs<br>
Business Object:POJOs<br>
Persistence: SQL Maps, DAO<br>
URL:http://www.ibatis.com/jpetstore/jpetstore.html<br><br>
 
xPetStore (EJB Implementation)<br><br>
 
Goal: To provide a pure EJB solution based on JSP, Struts, Sitemesh, EJB 2.0 and CMP 2.0 <br>
WebTier: JSP,Sitemesh,Struts<br>
Business Logic: Session Beans<br>
Business Object: Entity Beans<br>
Persistence: CMP<br>
URL:http://xpetstore.sourceforge.net/xpetstore_ejb.html<br><br>
 
xPetStore (Servlet Implementation)<br><br>
 
Goal: To provide a Servlet based solution using POJOs and Hibernate as persistence Framework<br>
WebTier: Velocity, Sitemesh, Webwork<br>
Business Logic: Webwork<br>
Business Object: POJOs<br>
Persistence: Hibernate OR-Mapper<br>
URL:http://xpetstore.sourceforge.net/xpetstore_servlet.html<br><br>

JDXPetStore<br><br>
 
Goal: Replace Entity Beans With POJOs; use JDX OR-Mapper for persistence of POJOs<br>
WebTier: JSP,Servlets<br>
Business Logic: Session Beans<br>
Business Object: POJOs<br>
Persistence: JDX OR-Mapper<br>
URL: http://www.softwaretree.com/products/jdx/JDXPetStore.htm<br><br><br>

Regards,<br>
Chaya & Rajini<br>
</body>
</html>

Let me be the first to burn you by saying that's really lame to try and charge for the pet store. Sad sad sad.

I'm afraid this go far to paying off your student debts...

I'm afraid this go far to paying off your student debts...

Apologies... meant to say "won't go far". Oh and you might want to check your demo site, it's currently not working.

Fortunately, we did not have to take out any loan for our education. We
have really enjoyed working on this project and hope that others can benefit from our work.

There is no online demo. Instructions for configuring and running the new
implementation are provided with the download package.

The world's gone mad, yet another damn pet store! Has anyone actually ever seen a real internet petstore? Perhaps we should have a competition for the most useless enterprise application.

- A web based greenhouse watering system
- A J2EE egg timer with web front end
- Microsoft Project with EJBs
- A Poodle trim booking system

Software Tree's web site give me great confidence on their products, you announce a world's best pet store (Zzzzz) and then lead your latest news off the front page to this...


Not Found
The requested URL /products\jdx\JDXPetStore.htm was not found on this server.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.


Good stuff, did someone say it costs money too?

-John-

Guys, virtually nothing works on your web site, most of the links fail (see my previous message) and when you finally find a page that does work the images are missing, add to that the HTML is actually Microsoft Word. REALLY SAD!

I suggest you spend a little time looking after your own web site before you announce a product, I was going to have a look at it but I have no reason to believe your code is any better than your web site.

By the way, since my last posting I wrote a really great OR mapping tool that integrates with a Flash front end, it's 6,000 times faster than Spring and almost 2 million times faster than Sun's original version try out the link...

http://www.softwaretree.com\products/jdx\..%5C..%5Cimage%5Cimg7_r1c1.jpg

By the way, you have to pay me $99 to see the code. :-)

-John-

Sorry about the link error that happened at the time of the last update of the web site. It has been fixed now. Thanks.

Since PetStore is a well-known application, it is easy to do and explain experimentation around it. Your project ideas look interesting. During dotcom fever, some of them could have been even VC-funded:)

-- Damodar

have you guys seen this? they have a patent for Object Relational Mappers?

 US6163776: System and method for exchanging data and commands between an object oriented system and relational system
http://www.delphion.com/details?&pn=US06163776__

Do you mind revealing the patent application? You obviously couldn't have received a patent as yet because it takes 3 years to get a patent. I'd like to read your pending patent application...


Reading some of the other comments, I've got to say, if you didn't bother paying the patent attorney $$$ and USPTO some more $$$ perhaps you wouldn't have had to put your source code on sale...

Do you mind revealing the patent application? You obviously couldn't have received a patent as yet because it takes 3 years to get a patent. I'd like to read your pending patent application... Reading some of the other comments, I've got to say, if you didn't bother paying the patent attorney $$$ and USPTO some more $$$ perhaps you wouldn't have had to put your source code on sale...

Yes, the patent system is very expensive! Your insightful comments have really gone straight into the heart of the matter:)
 
Software Tree has been around for more than 7 years now. Our patent was issued in December 2000. It has been commented on in another TSS thread before. I don't have anything more to add to that.

Regards,

-- Damodar Periwal

Software Tree, Inc.
Simplify Data Integration

what the hell these amateurs trying to do?
is this a kind of insult? you are building a school kids' project
and charging its f. code for money ha!
are you from stupid ms dev camp where they charge dummies for 'form.visible=true' kind of code for thousands of dollars.
Please be serious and act professionally.
If you try to charge something think about twice: There are already many state-of-the-art frameworks like Hibernate, Spring,etc., offered for free. Do you think you have done better?

Interesting comments. I guess we won't be getting business from you.

All of us sell some software, I probably will never buy O/R mapping tool too, but it is interesting to learn about technology.

Editorial: The TMC petstore case studies did significant benchmarking, so it would be interesting to see what the *real* difference is between this POJO version. Many people thought that the iBATIS version would win and it didn't

Although I was involved with the case study application specification, we did NOT use the iBATIS JPetStore implementation (nor the iBATIS persistence framework). At most, we re-used the presentation layer (Struts and JSP pages). There was a very clear restriction keeping O/R mappers and other persistence frameworks (e.g. Hibernate) from being used in the study.

Also, there were no "winners" in the case study. It was NOT a competition. It was a case study, and different people will draw different conclusions from it.

Cheers,
Clinton Begin
www.ibatis.com

I wonder if anyone ever tried to do Pet Store on JDO?
What kind of performance gain it will be to compare to EJB impl.

I wonder if anyone ever tried to do Pet Store on JDO?What kind of performance gain it will be to compare to EJB impl.

It depends how you will implement it, It is possible to "prove" both are very good and both are very bad.