EJB3/JBoss vs. JDO2/Kodo

Question

Hi,
does anybody here per chance have a (convincing ;) feature comparison between
EJB3/JBoss and JDO2/Kodo (Enterprise)? I'm not talking about support here, as that
can be purchased for JBoss as well.
My intuition says that Kodo is better technology and e.g. has better documentation,
but unfortunately that's too subjective to convince anybody else (which I'd really
like to).
Thanks for any information,
J__rg.

Answer 1

Thank you a lot for this even longer answer! Whenever someone asks me again why we
should go for Kodo, I'll give him a printout of this mail, just saying to him "read
this" ;)
Neelan Choksi schrieb:
It is clear that Kodo 4 complies to EJB3 (although it is notproduction-ready
currently).No implementation that supports EJB3 is production ready currently. That
is simply because the EJB3 specification just moved into public draft 2
weeks ago. There are still a lot of changes that are taking place in the
EJB3 spec (simply compare the Early Draft to the Public Draft and you'll
see how much things are changing). I am not criticizing the spec - I am
just pointing out that the spec is at a specific point in its life cycle
and there are a lot of really smart people including our CTO Patrick
Linskey trying to make sure 1) it is a good specification and 2) trying to
drive the specification forward to completion.
That said there are a lot of O/R Mapping products that are production
ready. I am going to limit my comments in this thread to focus on what
Kodo, the product, does well and not go into the differences in the
specifications.
I would also encourage you to take a look at both specifications and
determine which specification is right for you. Although fundamentally
similar, I believe certain developers will feel more comfortable with JDO
and certain developers will feel more comfortable with EJB3.
One distinguishing characteristic about Kodo is that you can use EJB 3 and
JDO 2 interoperably. This is a very big difference than some of the other
products that are on the market esp. since each specification has things
that the other specification is missing. Kodo gives you the best of both
worlds and allows you to choose how much of each world you want to use.
A pattern that we see emerging is that a lot of new customers are excited
to use our JDO standard support today and get the productivity gains that
Kodo provides today. While they wait to see if EJB3 Persistence meets
their needs and while they wait for their companies to adopt the
technology that EJB3 requires (JEE 5 and an app server that supports JEE
5), they will get the benefits of a solid O/R mapping tool that is based
on a standard. Over time, the interoperability that Kodo provides will
allow them to migrate piecemeal to EJB3 Persistence as it matures, thereby
managing their risk of adopting new technologies. Some of our customers
will migrate quickly and some have no plans of migrating ever. In any
case, Kodo provides a pathway for them.
But I can get the JBOSS implementation of EJB3 for free, why should
I pay
more for Kodo when it doesn't give me more functionality or performance?Abe has highlighted a number of technical features that distinguish Kodo.
I would encourage you to evaluate those features in a serious manner.
Often times we see other products who claim to have a given feature that
is in Kodo but when you actually use the feature, there are big
differences in quality and functionality. For example, I know that a
number of O/R mapping products claim to have a JMX management console but
I also know that the depth of functionality that is specific to O/R
mapping and ease of use of Kodo's Management Console was a big enough
differentiator that clients have asked to purchase the Management Console
standalone (FYI, to date we have not chosen to sell it standalone).
Regarding performance, this is one of the hardest things to compare.
We've been asked often if we have benchmarking numbers. The problem with
benchmarks is that a benchmark can be written to say anything you really
want. I would encourage you to benchmark for your specific application.
When properly tuned, I have not seen Kodo lose a benchmark since we
released Kodo 3 over a year ago. And we've seen some wins that have
really excited us e.g., Kodo + relational database has beaten existing
applications with object databases in performance / scalability
comparisons.
I also would like to highlight that a big differentiator between Kodo and
other products is the business model each employs. SolarMetric's focus is
selling product and occasionally selling services. As such, we do things
like take the most common of our experiences with performance tuning and
the most common support cases on performance / scalability and generalized
them into a chapter on optimizations techniques in our documentation. We
created the Management Console and Profiler to help customers resolve
their own performance / scalability issues. Other organizations that have
different models, e.g., solely services, are not motivated to provide this
level of best practices documentation and / or tools because that cuts
into their ability to provide services work.
I'm often in the same situation like J__rg. Always defending the decision touse
kodo (and doing so in future times) against statements like 'if we switch toEJB
why stay with kodo if we can get everything with JBoss/Hibernate for "free" 'Ok, even the JBoss guys admit that they are a business (there are some
recent interviews with Marc Fleury where he distinguishes between open
source hobbyists and professional open source where the goal is to
generate revenue). The reality is that how JBoss makes money is different
than how SolarMetric makes money, but nonetheless JBoss has to make money
to stay in business and to keep their investors happy just as SolarMetric
does.
What we've found interesting over the past few months is that many of our
enterprise customers who need support services and indemnification
protection have found that Kodo breaks even with open source solutions
when analyzed over a 1-2 year span and is dramatically cheaper over a 5
year span (simply comparing the costs of license and support between the
two). When factoring in other things e.g., quality of support, attitude
of support personnel, cost of training, quality of training, ease of use,
cost / time of contributing to the open source project, cost of digging in
the code of the open source project, Kodo has a lower Total Cost of
Ownership (TCO).
One final point to highlight with Kodo is that our model is not based on
certain customers of ours subsidizing all of the rest of our customers.
Such a model has a lot of business risk associated with it because the
customers that are willing to pay for services are customers that are
highly coveted. It is often dangerous to wake sleeping giants and put
your business at risk (see
http://www.forbes.com/home/intelligentinfrastructure/2005/06/15/jboss-ibm-linux_cz_dl_0615jboss.html).
I guess the bottom line is that JBoss/Hibernate or other open source
alternatives aren't free whether you look at out of pockets costs, TCO, or
risk.
Anyway. I'm convinced of kodo's robustnest - never had less problems whenusing
a third party product. If you describe a feature in the manual usually itworks.
Also the good pluggable architecture was worth its money ... it helpedeverytime
other implementation surely would have let us down.
Unfortunataly that are all things that you only realize, when you use it and
they are pretty difficult to communicate to decision makers, who are aboveme ;-)
Thank you for the compliments. I believe that the competition we've faced
supporting standards has made us quite bit stronger than products that
have been historically proprietary. The challenge with proprietary
products (e.g., TopLink and Hibernate) was that once you used them, you
have to re-write your entire data access infrastructure to switch away
from them. Having to support standards (JDO historically and now EJB 3)
for the past 4 years has meant that we've faced severe competition and the
only way for us to succeed was to build superior quality products that
have more functionality and better scalability and performance than
anything else out there. If we didn't, our customers could simply pick up
another of as many as 25 JDO implementations and try it out to see if
there was something better.
That said, the fact that our differentiators are a bit more subtle is one
of the challenges that we face as a business. A lot of the things that
differentiate Kodo e.g., Profiler, Management Console, Large Results Sets
Handling, Custom Fetch Groups, Lock Groups, Query Editor, etc. are things
that typically aren't evaluated very closely in a typical time-constrained
evaluations, but are absolutely critical when deploying in production
environments and when using Kodo with Agile Programming Methodologies.
The pluggable architecture that you reference is also very important
because many of our customers have constraints that prevent them from
fitting into a specific box. Again when a prospect does an eval, they
typically evaluate standard mappings and base functionality but the
reality is that the real world often brings up issues that no matter how
good the implementation is there will be something that isn't supported.
In our opinion, a pluggable architecture provides a cleaner way of
allowing customers to customize what they need rather than digging into
someone else's source code.
The things that we've heard from customers who have switched from other
solutions are:
- Kodo produces extremely clean SQL relative to other tools and
consequently has better performance and scaling characteristics
- Kodo's documentation and error messaging are extensive and makes
debugging quite easy
- Kodo's javadocs are extensive and provides a useful framework to
customize a wide variety of things.
- When tuning an application, Kodo provides a number of facilities and
tools for doing so relative to any other O/R mapping tools out there.
- Kodo's tooling is a large differentiator; in particular, the Kodo Query
Editor, the Profiler and the Management Console are often cited as
distinguishing features.
Also, one additional benefit with SolarMetric is that we are independent.
Our agenda is very clear - we are trying to create value for you such that
we get paid. There are no hidden agendas e.g., using Kodo as a loss
leader to sell you an object database, an application server, an entire
stack of products, training, services, etc. We simply are trying to build
a high quality product that meets our customers' needs that works well
with all the other technology products out there.
I hope between Abe's post and this post, we have helped you with arguments
for your management.
I'd encourage you to evaluate yourself and give us feedback.
Also, do not hesitate to contact me directly with any specific questions
or if you want me to review any documentation that you put together for
your management.
Thanks for your questions and interest. Stefan, thank you for being a
loyal customer.
Neelan Choksi
SolarMetric
[email protected]
202-595-2064 (main)
512-542-9707 (direct)
Vote for Kodo JDO as the Best DB Tool or Driver (Category 2), the Best
Java Data Access Tool (Category 7), and the Best Java Persistence
Architecture (Category 11) in the JDJ Readers Choice Awards at
http://jdj.sys-con.com/general/readerschoice.htm.