10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Floyd Marinescu on Jun 07, 2006
I am going to extend Spring’s JpaDaoSupport class. This provides a convenience method for retrieving the JpaTemplate. If you have used Spring with JDBC or other ORM technologies, then you will probably be quite familiar with this approach. It should be noted that use of the JpaDaoSupport is optional. It is possible to construct a JpaTemplate directly by simply providing the EntityManagerFactory to its constructor. In fact, the JpaTemplate itself is optional. If you do not wish to have the automatic translation of JPA exceptions into Spring’s runtime exception hierarchy, then you can avoid JpaTemplate altogether. In that case, you may still be interested in Spring’s EntityManagerFactoryUtils class which provides a convenient static method for obtaining the shared (and thus transactional) EntityManager.Spring 2.0 documentation has also been updated with a section showing how JPA is supported in the same way as Hibernate or TopLink. At Java One, Rod Johnson mentioned to InfoQ that Spring is putting a lot of effort into ensuring portability into JPA integration, the aim being to easily allow the swapping of JPA providers such as Hibernate, TopLink, OpenJPA, etc.
2006 and 2007 will definitely see a lot of competition and innovation for the next defacto standard for transactional, persistent java web app development.
Indeed, but we should remember also that not all applications are web applications. For example, of the several hundred jobs currently requiring Spring in London (from www.jobserve.co.uk yesterday) there are pages and pages of banking and other financial sector jobs, many of which are not web applications.
Innovation and competition is good. I'm looking forward to the developments of the next couple of years and I think the user community will be the big winner.
Remember the bad old days when people tried to apply the original Sun PetStore style J2EE architecture? When there wasn't vigorous innovation and competition in the space (because the EJB spec had all the answers)? We've come a long way and have further to go.
There appear to be three camps, Sun/JCP, JBoss, and Spring.
It's not clear to me at this point that Sun/JCP and JBoss are in two different camps. JBoss is advocating the use of Seam, but this is not an alternative to any of the JCP technologies.
on a practical aspect of this detbate: one feature of EJB3 that i find particularly interesting, innovative and potent is the combination of the extended persistence context and its injection into stateful EJB3 session beans: i, for my part, would only trust a fully Java EE 5 certified container (once this exists) to correctly implement all subtleties in this area of EJB3. The idea to have that same EJB container execute my unit tests outside the application server seems very convincing, IMHO.
cheers,
gerald
www.gerald-loeffler.net
There appear to be three camps, Sun/JCP, JBoss, and Spring.
It's not clear to me at this point that Sun/JCP and JBoss are in two different camps. JBoss is advocating the use of Seam, but this is not an alternative to any of the JCP technologies.
Note that we are working very closely with Sun and others to create a JCP-standard solution in this space. JBoss is deeply committed to the idea of innovating in open source, and bringing those innovations that work in practice back into the standards process.
We agree with Tim Berners-Lee that a technology well never be a universal technology if someone owns it. Monopolies stunt technology and stunt the growth of marketplaces.
Note that we are working very closely with Sun and others to create a JCP-standard solution in this space. JBoss is deeply committed to the idea of innovating in open source, and bringing those innovations that work in practice back into the standards process.There appear to be three camps, Sun/JCP, JBoss, and Spring.
It's not clear to me at this point that Sun/JCP and JBoss are in two different camps. JBoss is advocating the use of Seam, but this is not an alternative to any of the JCP technologies.
We agree with Tim Berners-Lee that a technology well never be a universal technology if someone owns it. Monopolies stunt technology and stunt the growth of marketplaces.
Indeed I did not mean to imply with the camps point that JBoss is not working with Sun, I agree that JBoss is committed to standards, as evidenced by the large contributions to the EJB spec.
The intention behind that point was to identify the groups that are actively developing and promoting their own approaches end to end stacks for web development, where these approaches have a real chance of becoming the next practical standard (as Spring Hibernate has).
Spring JPA or EJB3 JPA will be problematic as long as the JPA standard has critical missing features, namely a Criteria API and Filters, which I've become addicted to in Hibernate.
Rod has talked about implementing this stuff in Spring's JPA support, which would be excellent if it can be made portable across implementations (at which point it should be rolled into JPA 2), but until then people like me will have a hard time justifying a switch from Hibernate or JDO, both of which are richer in these other areas, to a JPA provider.
JPA will be problematic as long as the JPA standard has critical missing features, namely a Criteria API and Filters, which I've become addicted to in Hibernate. .... people like me will have a hard time justifying a switch from Hibernate or JDO, both of which are richer in these other areas, to a JPA provider.
The reason that JPA does not have a Criteria query API, or anything like Hibernate's unique Filter functionality is that these things were judged to be pretty exotic features. No, JDO absolutely does not have either of these features. No, AFAIK, there is no other product on the marketplace which has a Hibernate-like Filter construct for dealing with temporal/regional data.
RE: The reason that JPA does not have a Criteria query API, or anything like Hibernate's unique Filter functionality is that these things were judged to be pretty exotic features.
I agree with Jason Carreira. I don't find the Criteria API exoctic at all. I tend to use it a lot for filterable, paginateable tables. It helps me deliver a rich user experience.
I look forward to Spring (or some framework) providing a common Criteria API.
Innovation and competition is good. I'm looking forward to the developments of the next couple of years and I think the user community will be the big winner.
The user community will definitely be a winner. The vendors that produce the most innovative, or at least the most used products and services will also be big winners :).
Remember the bad old days when people tried to apply the original Sun PetStore style J2EE architecture? When there wasn't vigorous innovation and competition in the space (because the EJB spec had all the answers)? We've come a long way and have further to go.
I thought that there were lots of architecture styles in the "old days." IBM, Sun, Microsoft and other shops had their own solutions. J2EE consolidated some of those architectures. As a result, the user community was left with a difficult period of trying to understand what to do with the new architecture. Some inevitable push-back happened and then we went back to more consolidation...
"Unless simple things are simple, complex things are impossible" (Alan Kay). Innovation makes complex things are simpler, and in turn that makes some "impossible" things merely "complex."
I think we'll always have "further to go." There's probably room to go further in lots of different directions.
I implemented a Java DSL (API) for Criteria queries for JPA.
See.... www.jroller.com/page/RickHigh?entry=i_implement...
For more details.
You can even download it here...
code.google.com/p/krank/
Enjoy... Let me know what you think
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.
10 comments
Watch Thread Reply