Develop Reference

JPA Entity Manager why to use?

I've got involved in a project with entity manager in it. It's a bit unclear why should one use it. We have databases to store information in if we don't we can use classes to store informations in without the entity manager. The question is is it worth the effort to learn? Is it a widely used tool?
I know it's a bit opinion based but I'm interested in the facts mainly. But usually others experience shows how good a tool is.

Yes, JPA and Hibernate are widely used. Their benefits are the speed of the development (especially on the early stages of the project), but since it's a very complicated technology not everyone gets to use it effectively.
Ultimately knowing JDBC and databases is much more important than knowing ORMs. Mostly because everything else related to DBs in Java (including ORMs) is based on JDBC. But also if you need to write a very performant code - JDBC could be the right level of abstraction for you.
If you want to learn ORMs I'd advise to start with the book POJOs In Action - it explains the fundamental principles behind these frameworks. And after that check out Java Persistence with Hibernate - this one is more technically involved and describes all sorts of features in Hibernate.
Apart from the fully-featured ORMs there are lighter technologies that ease up the low-level JDBC burden: jOOQ, Spring JDBC, MyBatis.

Business logic: moving from stored procedures to BRMS. Pros and cons [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We're developing an application which implements business logic in stored procedures on an Oracle database. It has been this way for a few years.
The business rules are many, diverse and get often customized for specific customers.
Currently they're somewhat intermixed with data management and data retrieving code.
I've been thinking of proposing to move some of the logic in a BRMS.
My colleagues are likely to oppose that because:
they experienced that the current implementation based on PLSQL is considerably more efficient than one having logic implemented in the middle tier, i.e. in Java.
Our users often do really need short response time from our software, because it also directs their operations in industrial environments.
our team is not big and the people most knowledgeable about business rules are also the ones that implemented the stored procedures. They're not used to work with Java and, above all, using PLSQL allows us to ignore all the cruft regarding frameworks, system integration and mapping between different tiers.
If we're going to switch to something else other than PLSQL it has to be something that doesn't require lot of java coding and is possibly framework independent.
PLSQL allows to leverage the application's weight onto an expensive DBMS. Ideally we'd like an effective integration between BRMS and DBMS.
To better present my proposal I'd need some objective figures about the following issues:
performance penalty for moving from stored proecdures to BRMS
integration between DBMS and BRMS
abstraction offered by BRMS compared to the one offered by PSLSQL and pure java code
training needed to for the switch
I looked on the net and found a few references. Unfortunately most of them compare implementations being either pure Java code vs stored procedures or pure Java code vs BRMS. I couldn't find anything comparing stored procedures and BRMS, or that describe how to integrate a stored-procedures solution with a BRMS.
Many thanks.

If you select a well established engine, it is VERY likely that performance of the rules engine will be much better than performance of a system that access a database to retrieve and evaluate rules. The engine that we are using at the moment can evaluate about 2 million objects against a single complex rule in about 50 milliseconds. That's 2 million complex objects.
One of the features of an engine should be a UI that allows business people to create and manage their rules,not programmers. With proper engine, programmers SHOULD NOT create and manage rules, ever. You are probably looking at the open source engines (Drools, etc.) They generally miss this point. That's why you have an impression that your guys will have to learn Java in order to create business rules. That's a wrong assumption to begin with.
The entire point of a business rules engine is to abstract your business logic from the main code. Your database-based system does not offer the level of abstraction the normal BRE would. I don't know your system but I'm 99.9% positive on that, based on what I know about engines and "database rules systems". You need a database to store rules. That's all.
That depends on the engine you choose. Training is usually minimal for IT and somewhat mid-average for business.
Hope this helps.

Oracle has a built-in rules engine, which is not widely publicised. However it's built with PL/SQL and of course the interface to it is PL/SQL.
I have used it for a few ETL tasks but nothing that required high performance for bulk data. If you are willing to sacrifice some performance for flexibility however I'd recommend it.
http://docs.oracle.com/cd/B19306_01/appdev.102/b14288/toc.htm

Does the use of nosql (say mongodb) increase development productivity? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I develop 3 to 4 Spring Roo applications a year currently with Hibernate and MySQL. It has been stated here at Stackoverflow that relational databases are not the best fit for a typical object oriented webapplication .
If your DB is 3NF and you don’t do any joins (you’re just selecting a bunch of tables and putting all the objects together, AKA what most people do in a web app), MongoDB would probably kick ass for you.
There are various reasons for this. One is productivity as objects are mapped to a relational schema ("joins" etc.). Would the use of MongoDB or CouchDB increase development productivity given the same level of expertise as with MySQL?

I think it really depends on the web application. Non-relational databases (NoSQL) excel where you either
Don't want a schema (want to be able to store different sorts of data in the same table), and/or
Don't have too complex of relation between objects.
NoSQL can definitely make it easier to get off the ground faster, because you can just throw stuff in however you want, but on the downside as things get more complex sometimes you want a little more forced organization. Foreign keys are something I really miss when working with Mongo, just being able to (using an ORM) hop from one object to a related one or set of them is great. (Yes in many NoSQL dbs you can store documents, but at some point you need to use a separate table for something.)
I would highly recommend NoSQL for a brochure style website, where the client is just entering text fields, or a twitter-style site, where largely you are storing lots of one type of data with few attributes. But if you're going to be creating a CMS with revisions and workflow and such, you're going to want the ability to have explicit relations in SQL.
Which brings me to my answer: use the right tool for the job. A trained developer would be able to make some sites faster and better with SQL, and other sites faster and better with a non-relational database.
But try out MongoDB or CouchDB and get a feel for it, that way you'll have a better intuition on when to use what. (We use both at my job (not at the same time!) depending on the project)

How mature is Ebean or Siena? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
In the last time I heard a lot of complaining about Hibernate. And indeed I have some painful experiences with Hibernate too. So I read about Ebean and Siena.
Both have interesting approaches. Unfortunately, database access layers are very easy to write, but if your project grows and you have to handle great database-tables, you know if they are good or not. So it's really difficult to evaluate such a tool. Hibernate is well known and you could be sure that you can solve your problem with it. Sometime you need to learn a lot, but you can solve it.
How is it with Ebean? Are there any real world applications? Which databases are supported? Is it reliable?
After searching a little bit more I see that there are a lot more ORM-frameworks, so is there at least one reliable one?

Rob (Ebean Committer) here.
Ebean is about 4+ years old now. I would say it is fairly mature now. The supported DB's include Oracle, MySql, Postgres, H2 and SQL Server (and recently SQLite). Ebean is doing stuff that other ORM's are not such as Autofetch (automatic query tuning) so I'm not how that fit's into a 'maturity rating'. IMO the Ebean community is relatively small though so you probably need to hit the Ebean google group to engage them.
Any real world applications? Yes, but you are best to ask the Ebean community about that really. Certainly there is good support for batch processing (batch size, turn of cascading persist for a transaction etc) and large query support that I don't see in JPA etc (you might get something similar with Hibernate's Sessionless support).
Hopefully this might answer some small parts of your question anyway.
Cheers, Rob.

I'm currently a developer of Siena but not since very long. Let me explain why I became a developer on this project?
I went to Siena because I wanted to use Play+GAE and Siena appeared to be a good start for GAE DB and I really wanted to avoid JDO/JPA.
Then, I began to really appreciate Siena for its straightforward, light and easy approach and so simple APIs. It doesn't pretend to be the all-in-one abstraction layer like JDO and the greatest standard DB API like JPA. It really made me think of DB APIs from Python/Ruby and it really fits my point of view: I want a simple DB API which allows me to solve the great majority of my problems and when I have a more complex problem, I will use the lower layer APIs but certainly not an abstraction layer such as hibernate.
The possibility to make my code work on GAE DB or JDBC was also a good aspect. Once again, Siena doesn't pretend to provide exactly the same things in both worlds because SQL and NoSQL are not really compatible (but ORM is neither really compliant to SQL model :) ).
But once again, it is quite practical to be able to rely on the same APIs in several DBs.
Finally, the library is ONE jar and you don't have to retrieve the whole universe to use it.
So, I became progressively a committer on Siena because I wanted to take part of this nice little adventure.
Now siena team is working on a new version keeping the same simple APIs, bringing new interesting features and really improving all the backend code to make it even easier to extend for new DB support.
Siena is a pragmatic API driven by user experiences and that's why I like it ;)
Pascal

We've had really great experience with MyBatis, which is not an ORM per se, but another class of persistence manager, an SQL Mapper. Using it you start with SQL statements and direct it on how to map result rows into POJOs. It's conceptually easy to understand and tune with not much magic going on inside. It's ideal if you are comfortable with SQL or need to work with an established schema.

Besides Ebean and Siena:
You can try JIRM which is focused on CRUDing immutable objects (yes I'm the author).
There is also jOOQ and Joist.
I feel that JIRM minimizes the number of DTO's because the domain objects are immutable and do not inherit, implement and/or are not "enhanced/instrumented". Such is not the same with Siena and Ebean.
Also because the objects are Immutable there is more of a focus on per column updating instead of the whole object which makes more sense given today's AJAX interfaces (compared to the old POST the whole bean model).

What about using EB3, with for instance JBoss (www.jboss.org)?

I need a simple rules engine, I think? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I need some advice on the best approach to solving this problem.
I've researched DROOLS, Java Rule Engine and a few others. All of these are powerful, and have good things about them. I don't know which (if any) will be the best choice for me.
I have one business object. (simplified for demo)
Person
firstName:String
lastName:String
departMent:String
hireDate:Date
I need to write an editor in a web application that will allow for complex rules to be built around these fields. I need to support complex nested AND/OR logic. I just need basic operators, and the rule should simply evaluate to true or false. If the rule evaluates to true or false, one action will occur respectively.
For example,
firstName CONTAINS "value" AND
(lastName EQUALS "input" OR department
CONTAINS "input")
I had thought, maybe I should just write my own parser and evaluate the logic in my own code. I don't know what to do, any advice or links to something to read would be greatly appreciated. Is there a specific design pattern I could research?
How would you solve this problem? One reservations about the rules engines is that maybe they are too complex for just a simple problem?

This is not an yes/no question, but I can probably share my experiences, and hope it helps.
I have used DROOLS quite successfully in a few projects. Apart from some cases (another team had issues with DROOLS under heavy load,) DROOLS is quite an useful library.
I built an application which:
1. read input from a source
2. chose the next action based on the input from a set of available operations
As trivial as it looks, it needed to be very flexible:
1. The input was a variable set of name-value pairs, names not predetermined.
2. values, presence/absence of certain name/values (based on occurrence/absence of events), trigger different actions.
3. The business rules can change while the application is running.
Maybe there are better solutions, but for better or worse, I ended up using DROOLS. I developed a BPEL in which the decisions are made by the DROOLS component. The DROOLS component internally reads the decision making rules from a Microsoft Excel spreadsheet. It rebuilds the rules if there is a change in the file.
Now the domain experts change this spreadsheet when required, and we do not go through painful deployments!
If you want a sophisticated UI, DROOLS Guvnor is a readily available web-application (with rich UI,) which would help your domain/subject-matter experts to build rules and store them in a database.

The Drools documentation talks about when to use a rules engine. http://downloads.jboss.com/drools/docs/5.1.1.34858.FINAL/drools-expert/html_single/index.html#d0e181
From the docs...
The shortest answer to this is "when
there is no satisfactory traditional
programming approach to solve the
problem.". Given that short answer,
some more explanation is required. The
reason why there is no "traditional"
approach is possibly one of the
following:
-- The problem is just too fiddle for
traditional code.
The problem may not be complex, but
you can't see a non-fragile way of
building a solution for it.
-- The problem is beyond any obvious
algorithmic solution.
It is a complex problem to solve,
there are no obvious traditional
solutions, or basically the problem
isn't fully understood.
-- The logic changes often
The logic itself may even be simple
but the rules change quite often. In
many organizations software releases
are few and far between and pluggable
rules can help provide the "agility"
that is needed and expected in a
reasonably safe way.
-- Domain experts (or business analysts)
are readily available, but are
nontechnical.
Domain experts often possess a wealth
of knowledge about business rules and
processes. They typically are
nontechnical, but can be very logical.
Rules can allow them to express the
logic in their own terms. Of course,
they still have to think critically
and be capable of logical thinking.
Many people in nontechnical positions
do not have training in formal logic,
so be careful and work with them, as
by codifying business knowledge in
rules, you will often expose holes in
the way the business rules and
processes are currently understood.
When not to use...
As rule engines are dynamic (dynamic
in the sense that the rules can be
stored and managed and updated as
data), they are often looked at as a
solution to the problem of deploying
software. (Most IT departments seem to
exist for the purpose of preventing
software being rolled out.) If this is
the reason you wish to use a rule
engine, be aware that rule engines
work best when you are able to write
declarative rules. As an alternative,
you can consider data-driven designs
(lookup tables), or script processing
engines where the scripts are managed
in a database and are able to be
updated on the fly.

I would suggest your own parser. In this context why can't you serialize the object and use AJAX to validate it in the back end? It then seperates the validation logic from the UI.

I would take a look at some sample rules engine interfaces and see which ones I like. You can look at web based email rules interfaces to get some ideas. If you really need a simple rules engine, you just need to create a good interface, and then you can send the rules to the server with javascript.

Probably not. You need a decent domain model. Not one where your objects are just data placeholders. Are your users likely to be able to understand and use such a complex rules system, and wouldn't those that do prefer just programming in java, where they have proper encapsulation and refactoring support? Rules systems only work with simple rules on a restricted domain, where you can explain people not trained as programmers how to build them. And don't forget rules building is just programming, so you still need version control, tests, and don't want globals.

Wouldn't Jython be usefull?
Each expression/complex-rule could be the body of a function.
So the user provides the body, and your code puts the function spec around it, and then execute it.
You can also put any Java objects / variables of your own into the jython context to be used in your script/ function body.
Then you have a standardized, extendable widely used language at your fingertips.
But i think the Jython editor could be a challenge.

Have you tried JBehave?
JBehave is a framework for Behaviour-Driven Development (BDD). BDD is
an evolution of test-driven development (TDD) and acceptance-test
driven design, and is intended to make these practices more accessible
and intuitive to newcomers and experts alike. It shifts the vocabulary
from being test-based to behaviour-based, and positions itself as a
design philosophy.