> -----Original Message-----
> From: David Nalley [mailto:[email protected]]
> Sent: Friday, June 29, 2012 10:37 AM
> To: [email protected]
> Subject: Re: Hibernate
>
> On Fri, Jun 29, 2012 at 12:13 PM, Rajesh Battala
> <[email protected]> wrote:
> >
> >
> >> -----Original Message-----
> >> From: David Nalley [mailto:[email protected]]
> >> Sent: Friday, June 29, 2012 8:40 PM
> >> To: [email protected]
> >> Subject: Re: Hibernate
> >>
> >> On Fri, Jun 29, 2012 at 9:27 AM, Rajesh Battala
> >> <[email protected]>
> >> wrote:
> >> >
> >> > Shall I proceed to replace Hibernate Framework with Spring JDBC.
> >> >
> >>
> >> This is not a design decision to take lightly, or rush - as we've
> >> talked about replacing the custom ORM that CloudStack uses as well -
> >> we'd want to make a decision on something that we are comfortable with
> in that role as well.
> >>
> > [Rajesh Battala]
> > So we are planning to implement some ORM framework for CloudStack also?
> > If so, then we need to evaluate the available ORM frameworks for java
> which are based on Apache License?
> >
>
>
> I don't want to speak for Alex, but I have heard him mention such a
> change number of times, and have seen it in his slides as well.
>
> But the larger sense is that if we are going to change something in
> AWSAPI for communicating to the database, it should be something that we
> are comfortable with adopting in the long term for the rest of CloudStack,
> otherwise we'll end up with two different ways for connecting to the
> database, which is fail.
For Rajesh's concern in the short term (to get rid of Hibernate), we basically
have following options,
1) Make the project depend on utils.jar in CloudStack and use existing
CloudStack persistent layer.
2) Continue to make CloudBridge project independent
a) use direct JDBC
b) use Spring JDBC
c) use ORM framework on Spring (i.e. OpenJPA etc)
I vote on 2-b for a short term resolution. For a couple of reasons,
The major reason is for adopting Spring, EC2/S3 API in the future may both need
to support SOAP based web service API and REST API, Spring comes with support
of both, in addition, it provides dependency injection, AOP and pluggable ORM
framework, distributed transaction management, etc.
CloudBridge project has a very simple data model (it has only one table for
EC2), original ORM (hibernate) usage is just for convenience (as Alex pointed
that it tried to avoid direct SQL manipulation), on the other hand, giving the
DAO abstraction, a limited amount of JDBC should not matter too much either.
With Spring and already existing DAO abstraction, we can leave bigger ORM
decision for the future.
In the long term, ORM choice to us seems to be secondary consideration, giving
the fact that our current custom ORM implementation serves its purpose well
enough in CloudStack. But I do see the needs of more flexible dependency
injection or transaction management framework in order to incorporate better
integration with external transactional systems like message queue servers. I
also see the needs of standardizing AOP patterns used in current CloudStack
code base, Spring provides some good answers for that. So there is a
possibility that it will be good for CloudStack to adopt it like many other
Java communities do, so that we can focus on our own business logic and leave
these external concerns to people who are doing it for a living.
Kelven
>
> --David
