We Keep Coding

Data persistence in Java Server Faces with Hibernate/JPA

I am planning to build a web application with Java Server Faces but i am unsure how to handle the persistence of my entities. For php projects i am using the Symfony framework with Doctrine 2. I call the persist method of the entity manager mainly in the controllers. So there are no seperate classes for business logic. I tried Hibernate and i think that is a good replace for Doctrine. ;)
The java project is for university and i want to transfer the business logic from the controllers/beans to classes for business logic.
I read articles and tutorials about the data access object and repository pattern (http://docs.spring.io/spring-data/jpa/docs/1.3.0.RELEASE/reference/html/jpa.repositories.html).
In the data access object pattern i have a class for my Entity and an interface and a class for my DAO object/entity, in the repository pattern i have a class for my entity and a class for the repisitory.
But where goes my business logic? Do I have to write an interface and a class per entity for the business logic layer and inside the classes i simply call my dao/repository methods? If so, what is the difference between both patterns?
If I am totally wrong: What is the (industry) standard for data persistence (with Hibernate/JPA) with Java Server Faces?

The architecture of the project must be well organized according to principle "low coupling and high cohesion"
The system layers should be well seperated. The basic architecture have 3 layers.
Presentation Tier: JSF managed beans are in this layer. The task of this layer is to correspond user actions, hold user data and show the data to the user. Basically, its responsibility is bounded by MVC pattern regardless of which implementation you use (JSF, Spring MVC or Struts)
Bussimess Logic Tier: The data and actions which was collected from page was sent to this layer to operate on data. You should not manipulte the data and prepare the response inside Presentation Tier. It is the responsibility of Bussiness Logic Tier.(Spring, CDI)
Integration Tier: Database access should be done in this layer regardless of the library technology used (Hibernate, JPA, JDBC).
As you can see in the pic. your JSF managed beans should only be capable of requests from the pages(controller) and page data (model). You can have a look to this answer to understand JSF MVC. Therefore, It is better to not to connect DB inside JSF managed beans. It is not a good practice.
The second part of your question. All technologies, Hibernate, JPA, Spring JDBC, uses JDBC driver of the related DB. JDBC Drivers is the just thing which connects to the DB. However, it is beter to select a method how to connect to DB, Hibernate, JPA or Spring JDBC.
You can download my example application which implements this architecture basically.

Is it good to duplicate jpa entities for business objects?

I have a design/architectural problem:
I've started developing a java web application. I thought of using 3 layers: a persistence layer (with jpa and hibernate), a business layer and a presentation layer. My problem now is:
the jpa entities would make the model but can or may I use the entities as business objects?
Is this a practice? My common sense says I shouldn't, but then, I need to duplicate these entities as business objects?
Finally, I'd like the presentation layer to be really decoupled from the other layers. While using spring mvc with jsp at first, I'd like. if it's suitable, at some moment to switch to javascript-based application that communicates with the backend through rest requests.

Yes, you can. Outside the persistence context, the JPA Entities are like simple POJOs. It is legal to use them in business code (actually, as hinted by JB Nizet, you usually ALWAYS use them in your business layer without DAO). If it is tightly related to the Entity, you can even add business logic into your JPA beans. Nevertheless, it will be harder to read and understand what the code does. But if you have a reason to do that - there is nothing illegal. It all comes down to software design practices and what you need most.
When you want to change your app into the REST-powered service, it is not difficult. You will have to change the Servlet you are currently running your app with for a JAX-RS or other framework Servlet which will handle HTTP requests in a REST manner for you. It is done in web.xml. Then, you will place your html-pages in any place, where it is accesible for the remote hosts, and connect them to your REST-service with the Javascript AJAX or sth. You should take care of CORS then.

Data Integrity in DB Level in front of Web Services

Is there a possible architecture that a developer can think of when it comes to extending a web application by introducing Web Services to the existing architecture or vice-verse. The main concern in this context is the data integrity and security.
The following images will suggest two approaches that a developer can think of.
This architecture indicates that all the request should be handled by an individual service layer. Therefore, only the service layer can communicate with the Data Base and satisfy request for both the web application and the gate way.
The second approach shows the web application is directly communicating with DB. For an example an Admin Portal. Meantime there can be an external web services also communicating with the DB. This approach may lead to Data Integrity Violating scenarios. However, introducing external web services might be easier than refactoring an existing Web Application to call a web service from developer end. Hence, can we still compromise for the long term consequences by having external web service and a separate web application instead of both the Web Application and the Gateway being catered with a single web service layer. Any reasonable comment on this would be appreciated.

You could build an API that has access to everything. In other word, the web application could work trough a rest/rpc api using Ajax/WebSockets.
Since everything goes through the API, data integrity shouldn't be enforced at any time. Also, you'll get a clear separation from Client, Api and Database.
This will allow you to replace the database by anything else without breaking other parts of your system.

I would personally advise to have at least a shared data access layer which handle data validation and persistence.
The best way would be however as defined in your first diagram with a shared service layer to factorize transaction management which should be defined at this level. You could so take advantage of custom transaction isolation and / or locking policy in order to ensure Data integrity. Public service layer methods could be in this case directly exposed as rest services and consumed by both mobile and web apps (gateway / API component is not necessary).
All of this will depend on the estimated time to refactor the legacy app architecture on a way and to duplicate data access logic (and business one ???) on the other. Of course the duplication will decrease maintainability and extensibility.

I've had to answer this question on several projects; there's a 3rd option which you don't mention, which is my favourite.
The problem with option 1 - "web services as persistence and business logic layer" is that it introduces a lot of additional moving parts into the design. Those moving parts are expensive - you have to write, test and maintain a lot more code, and very often the services you want from your web services to run your own application are not the ones that would make sense to a 3rd party developer.
You are also introducing a potentially significant performance and scalability risk - calling a web service which calls a database is measurably slower than just calling the database.
The second option - duplicating business logic across web app and service layer - has all the problems of duplication.
The option I prefer is to develop the business logic layer as a separate component, and have it used by both the web app and the web services; each application uses the component as a library. This means you have to have separate teams - the "library" team and the "app" teams - but you avoid duplication, and you avoid invoking a bunch of web services every time you have to render a web page.
The business logic layer is responsible for persistence - including making sure that database consistency is honoured, and managing transactions. As the business logic layer is shared between both the web app and the web services, this logic is concentrated into a single code base, and - ideally - made entirely transparent to the apps.
The web services now do far less. Their job is to handle incoming requests, translate them into method invocations on the business logic component, and returning any response data in the appropriate format (XML, JSON). They may offer "coarse grained" service requests and map them onto several more granular business logic methods. They may deal with authentication, authorization, request throttling etc. They just don't deal with the actual business logic.

Usage of a Data Access Layer (DAL) in a SOA design

As we are in the beginning phases of rejuvenating our application in to SOA design I have some questions that I can not get a clear answer/picture on.
I have been doing a lot of reading, mostly around books from Thomas Erl and following that design pattern of understanding what Task Services, Entity Services and Utility Services are.
What I am stumbling on is the whole DAL concept of how that would look. So this is more of a verification of understanding or a clarification so as to help make the best approach for our platform.
So background. We currently have several web based e-commerce applications that have been pretty much been built in silos and are again pretty much a copy of each other. We have supporting applications such as Daemons and misc web services out there. Many of these applications are older then 5 years and are build on only technology (Model 1). All of our applications are centered around conducting auction sales. So during a sale event we will be taking bids from users, determine who is winning and display that information back. Each sale event has a set amount of time that they will be available to the users.
The company is moving towards a SOA solution as a lot of things we end up doing can be shared across not only our group but across other groups.
So what I understand on the DAL is that it in itself is a service which will sit on top of Data, in this case different Databases - MSSQL, ORACLE, MSSQL. Each of these databases have different schema's (Oracle) etc.
So the services (Task, Entity, Utility and Presentation Tier if needed) will make calls to the DAL to retrieve data. It is the responsibility of the DAL to know, from the contents of the message to determine what it needs to do in order to fulfill the request.
So for example, we have a Security Service candidate. This service needs to authenticate with LDAP and to authorize from the data that is stored for that given application.
The thought here is that a Utility service will be created to wrap up all the operations required to communicate with LDAP and that the Security Service will call upon the Utility Service and to the DAL to fetch the authorization data. The DAL then has the responsibility to go to the correct database/schema to retrieve the information. The information will be in XML format (standard SOA communication).
So, am I on the right track here? Have others done similar things or not? What other things do I need to consider (Currently getting the statistics on how many bids we take in an hour - on average).
Should each service have its own DAL - for example should the Security Service have the DAL as part of the service or should DAL be a shared service in which all services can use?

In your case, the approach to use for a full SOA based deployment would be to use an ESB, Identity provider and a data services solution.
To break it down, the DAL should be implemented using data services, in this way, this service will be a globally accessibly service in a language neutral way, and will support re-use and loose coupling. So all your data access logic can be implemented as web service operations in a data service.
So for the authentication and authorization management, in the SOA world, there's a standard called XACML, which is used for fine grained authorization management. So what you will need is an XACML server, who would authorize the user according to a specific criteria, where this should also have the ability to authenticate with LDAP.
Then your "Security Service" will be implemented in a service at the ESB, where that service will query the identity provider for authentication/authorization and according it's response, it will call the appropriate operations in the data service, with suitable parameters to fetch the data, and return it to the user.
The above scenarios can be implemented using WSO2 Data Services Server, WSO2 Identity Server and WSO2 ESB respectively, which are open source products, and can be freely used and found here.

i once worked with (developing) an soa project that used a "data service". it was some time ago, and i was only involved marginally, but my recollection was that it ended up being too complicated and slow.
in particular we had no real need for a data service - it would have made more sense to have placed the same abstractions in a library layer, which would have given better efficiency and no real loss of functionality (for our particular needs). this was exacerbated by the fact that the data tended to be requested in many small "chunks".
i guess it comes down to the trade-offs involved in the implementation. in our case, with a relatively closed system and a single underlying database technology, we could have easily exploited the support for distributed access that the database provided; instead we ended up duplicating this in a slower, more general, message bus, which added nothing except complexity. but i can easily imagine different cases where access to data is more "distant".

How you have to use SOA for your design is depends on the its requirements.
In generally you can write coarse grain services and expose them as web services. In your case you can write some services which calls the databases and produce the results. In this case authorization logic can also be written with the service logic.
The other approach is to use an ESB or BPEL engine to write the integration logic and expose the integrated service as a web service. In this case you can use some data services to expose data base data in xml format and integrate them. You can use services for different sachems and call the correct service with the request data. And the authorization logic can also be added to service integration logic.
Security aspects such as authentication, confidentiality, integrity is considered as non functional requirements and hence can be engaged to any service without writing an explicit security service.
Following articles describes such sample possible integration of services as mentioned in the second approach.
http://wso2.org/library/articles/2011/05/integrate-business-rules-bpel
http://wso2.org/library/articles/2011/06/securing-web-service-integration

Describe the architecture you use for Java web applications? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Let's share Java based web application architectures!
There are lots of different architectures for web applications which are to be implemented using Java. The answers to this question may serve as a library of various web application designs with their pros and cons. While I realize that the answers will be subjective, let's try to be as objective as we can and motivate the pros and cons we list.
Use the detail level you prefer for describing your architecture. For your answer to be of any value you'll at least have to describe the major technologies and ideas used in the architecture you describe. And last but not least, when should we use your architecture?
I'll start...
Overview of the architecture
We use a 3-tier architecture based on open standards from Sun like Java EE, Java Persistence API, Servlet and Java Server Pages.
Persistence
Business
Presentation
The possible communication flows between the layers are represented by:
Persistence <-> Business <-> Presentation
Which for example means that the presentation layer never calls or performs persistence operations, it always does it through the business layer. This architecture is meant to fulfill the demands of a high availability web application.
Persistence
Performs create, read, update and delete (CRUD) persistence operations. In our case we are using (Java Persistence API) JPA and we currently use Hibernate as our persistence provider and use its EntityManager.
This layer is divided into multiple classes, where each class deals with a certain type of entities (i.e. entities related to a shopping cart might get handled by a single persistence class) and is used by one and only one manager.
In addition this layer also stores JPA entities which are things like Account, ShoppingCart etc.
Business
All logic which is tied to the web application functionality is located in this layer. This functionality could be initiating a money transfer for a customer who wants to pay for a product on-line using her/his credit card. It could just as well be creating a new user, deleting a user or calculating the outcome of a battle in a web based game.
This layer is divided into multiple classes and each of these classes is annotated with #Stateless to become a Stateless Session Bean (SLSB). Each SLSB is called a manager and for instance a manager could be a class annotated as mentioned called AccountManager.
When AccountManager needs to perform CRUD operations it makes the appropriate calls to an instance of AccountManagerPersistence, which is a class in the persistence layer. A rough sketch of two methods in AccountManager could be:
...
public void makeExpiredAccountsInactive() {
AccountManagerPersistence amp = new AccountManagerPersistence(...)
// Calls persistence layer
List<Account> expiredAccounts = amp.getAllExpiredAccounts();
for(Account account : expiredAccounts) {
this.makeAccountInactive(account)
}
}
public void makeAccountInactive(Account account) {
AccountManagerPersistence amp = new AccountManagerPersistence(...)
account.deactivate();
amp.storeUpdatedAccount(account); // Calls persistence layer
}
We use container manager transactions so we don't have to do transaction demarcation our self's. What basically happens under the hood is we initiate a transaction when entering the SLSB method and commit it (or rollback it) immediately before exiting the method. It's an example of convention over configuration, but we haven't had a need for anything but the default, Required, yet.
Here is how The Java EE 5 Tutorial from Sun explains the Required transaction attribute for Enterprise JavaBeans (EJB's):
If the client is running within a
transaction and invokes the enterprise
bean’s method, the method executes
within the client’s transaction. If
the client is not associated with a
transaction, the container starts a
new transaction before running the
method.
The Required attribute is the implicit
transaction attribute for all
enterprise bean methods running with
container-managed transaction
demarcation. You typically do not set
the Required attribute unless you need
to override another transaction
attribute. Because transaction
attributes are declarative, you can
easily change them later.
Presentation
Our presentation layer is in charge of... presentation! It's responsible for the user interface and shows information to the user by building HTML pages and receiving user input through GET and POST requests. We are currently using the old Servlet's + Java Server Pages (JSP) combination.
The layer calls methods in managers of the business layer to perform operations requested by the user and to receive information to show in the web page. Sometimes the information received from the business layer are less complex types as String's and integers, and at other times JPA entities.
Pros and cons with the architecture
Pros
Having everything related to a specific way of doing persistence in this layer only means we can swap from using JPA into something else, without having to re-write anything in the business layer.
It's easy for us to swap our presentation layer into something else, and it's likely that we will if we find something better.
Letting the EJB container manage transaction boundaries is nice.
Using Servlet's + JPA is easy (to begin with) and the technologies are widely used and implemented in lots of servers.
Using Java EE is supposed to make it easier for us to create a high availability system with load balancing and fail over. Both of which we feel that we must have.
Cons
Using JPA you may store often used queries as named queries by using the #NamedQuery annotation on the JPA entity class. If you have as much as possible related to persistence in the persistence classes, as in our architecture, this will spread out the locations where you may find queries to include the JPA entities as well. It will be harder to overview persistence operations and thus harder to maintain.
We have JPA entities as part of our persistence layer. But Account and ShoppingCart, aren't they really business objects? It is done this way as you have to touch these classes and turn them into entities which JPA knows how to handle.
The JPA entities, which are also our business objects, are created like Data Transfer Objects (DTO's), also known as Value Objects (VO's). This results in an anemic domain model as the business objects have no logic of their own except accessor methods. All logic is done by our managers in the business layer, which results in a more procedural programming style. It's not good object oriented design, but maybe that's not a problem? (After all object orientation isn't the only programming paradigm which has delivered results.)
Using EJB and Java EE introduces a bit of complexity. And we can't use purely Tomcat (adding an EJB micro-container isn't purely Tomcat).
There are lots of issues with using Servlet's + JPA. Use Google for more information about these issues.
As the transactions are closed when exiting the business layer we can't load any information from JPA entities which is configured to be loaded from the database when it's needed (using fetch=FetchType.LAZY) from inside the presentation layer. It will trigger an exception. Before returning an entity containing these kinds of fields we have to be sure to call the relevant getter's. Another option is to use Java Persistence Query Language (JPQL) and do a FETCH JOIN. However both of these options are a little bit cumbersome.

Ok I'll do a (shorter) one:
Frontend : Tapestry (3 for older projects, 5 for newer projects)
Business layer: Spring
DAO's : Ibatis
Database : Oracle
We use Sping transaction support, and start transactions upon entering the service layer, propagating down to the DAO call's. The Service layer has the most bussines model knowledge, and the DAO's do relatively simple CRUD work.
Some more complicated query stuff is handled by more complicated queries in the backend for performance reasons.
Advantages of using Spring in our case is that we can have country/language dependant instances, which are behind a Spring Proxy class. Based on the user in the session, the correct country/language implementation is used when doing a call.
Transaction management is nearly transparent, rollback on runtime exceptions. We use unchecked exceptions as much as possible. We used to do checked exceptions, but with the introduction of Spring I see the benefits of unchecked exceptions, only handling exceptions when you can. It avoids a lot of boilerplate "catch/rethrow" or "throws" stuff.
Sorry it's shorter than your post, hope you find this interesting...

Ideal Java Based Web Development Technologies Today.
Web Layer :
HTML+CSS+Ajax+JQuery
RESTFul Web Controller/Action/Request Processing Layer :
Play Framework
Business Logic/Service Layer:
Use Pure Java Code as long as possible. One can do fusion of web services here.
XML/JSon Data Transformation Layer :
XMLTool(Search On Google Code),JSoup,Google GSon,XStream,JOOX (Search On Google Code)
Persistence Layer :
CRUD : JPA or SienaProject or QueryDSL /
Complex Queries : JOOQ,QueryDSL

Here's my 5 cents
Presentation
Android, Angular.JS WebClient, OAUTHv2
API
REST, Jersey (JAX-RS), Jackson (JSON de-/serialisation), DTO-objects (different from business logic models)
Business Logic
Spring for DI and Event handling. DDD-ish approach of model objects. Longer running jobs are offloaded with SQS in worker-modules.
DAO
Repository model with Spring JDBC-templates to store Entities.
Redis (JEDIS) for Leaderboards, using Ordered Lists.
Memcache for Token Store.
Database
MySQL, Memcached, Redis

What we have followed in our project is :
Front end Technology
AngularJS
HTML5
css3
Javascript
Bootstrap 3
API
REST
JERSEY (JAX-RS)
REST ASSURED
SPRING BOOT
Jackson
spring security
Business Logic
SPRING DATA
SPRING data MongoDB
Data base
MongoDB
Server (For caching)
redis

We are still using the usual Struts-Spring-Hibernate stack.
For future apps, we are looking into Spring Web Flow + Spring MVC + Hibernate or
Spring + Hibernate + Web Services with Flex front end.
A distinct characteristic of our architecture is modularization. We have a number of modules, some starting with 3 to max 30 tables in the database. Most of modules consist of business and web project. Business project holds business and persistence logic while web holds presentation logic.
On logical level, there are three layers: Business, Persistence and Presentation.
Dependencies:
Presentation depends on Business and Persistence.
Persistence depends on Business.
Business does not depend on other layers.
Most of business projects have three types of interfaces (note: not GUI, it is a programatic java interface layer).
Interface that presentation is using as a client
Interface that other modules are using when they are the client of the module.
Interface that can be used for administrative purposes of the module.
Often, 1 extends 2.
This way, it is easy to replace one implementation of module with another. This helps us adopt to different clients and integrate more easily. Some clients will buy only certain modules and we need to integrate functionality they already have. Since interface and implementation layer are separated, it is easy to roll out ad-hock module implementation for that specific client without affecting dependant modules. And Spring Framework makes it easy to inject different implementation.
Our business layer is based on POJOs. One tendency I am observing is that these POJOs resemble DTOs. We suffer from anaemic domain model. I am not quite sure why is this happening but it can be due to simplicity of problem domain of many of our modules, most of the work is CRUD or due to developers preferring to place logic somewhere else.

Here is one more web architecture I have worked on:
One major requirement was the application should support mobiles/other
devices. The application should also be extensible or flexible to
changes in technology choices.
Presentation Tier:
JSP/JQuery (Client-side MVC)
Native Android
Native iPhone
Mobile web (HTML5/CSS3/Responsive design)
Spring REST Controllers (Can change to JAX-RS)
Business Service Tier:
Spring #Service (Can change to Stateless EJB)
Data Access Tier:
Spring #Repository (Can change to Stateless EJB)
Resource Tier:
Hibernate(JPA) entities (Can change to any ORM)
You can find more information on the book which follows this architecture here.

IMHO, most of us have a common denominator. Atleast in the back-end, we have some form of IOC/DI container and a persistence framework. Personally I use Guice and Mybatis for this. The differences are in how we implement the view/UI/presentation layer. There are 2 major options here (may be more) .. Action based (URLs mapped to controllers) and component based. Currently am using component based presentation layer (using wicket). It perfectly mimics a desktop environment where I use components and events as opposed to URLs and controllers. Am currently looking for a reason why I should migrate to this URL-controller kind of architecture (that's how I ended up on this page). Why the hype about RESTful and Stateless architectures.
To answer this question in short: I write stateful web applications using a component oriented framework on top of Guice IOC container and put data in relational database using Mybatis.

A bit different, and I would claim more modular java architecture here. We have:
Spring WS/Rest/JSP front end
Spring MVC for business service logic, containing presentation layer logic as well as Spring transactions
Component service communication interface, looked up through EJB by business services. EJBs set their own transaction boundaries that are able to join Spring transactions.
Component service implementations, again Spring components
Integration layer, MyBatis for database integrations, Spring WS for web service integrations, other integration techonologies for other services
Mainframes, databases, other services at other servers...
In addition to the above, we have the shared library modules which is common functionality provider for all srevices.
Use of different layers allows us full decoupling and the modularity we need. We are also able to fully utilize the power of Java EE as well as Spring. Nothing prevents us from using JSF, for example, for the front end if needed.
Compared to example architecture by OP, I think this can be described as having four main layers instead of three, albeit with a twist.

I've worked on projects that use that rigid manager pattern. Historically, I was a huge proponent of the rigid hierarchy where everything fit into a neat box. As I progress in my career I find it to be forced in a lot of cases. I believe that adopting a more agile mindset towards application design leads to a better product. What I mean by this creating a set of classes that solve the problem at hand. Rather than saying "Did you build a manager for this and that?"
The current project I'm working on is a web app with a combination of Spring MVC and RestEasy JSON/Ajax calls. On the server side embedded in our controllers is a sensible facade based data tier with JPA/Hibernate for direct Database access, some EJB access, and some SOAP based web service calls. Tying all this together is some custom java controller code that determines what to serialize as JSON and return to the client.
We spend almost no time attempting to create some unified pattern instead opting to adopt the "Worse is Better" idea of the Unix Design Philosophy. Being that its much better to color outside the lines and build something sensible, quickly than it is to build something that adheres to a bunch of strict design mandates.

The components in Web Application Architecture include :
1 : Browser : Client interaction
HTML
JavaScript
Stylesheet
2 : Internet
3 : Webserver
CSS
Image
Pages(Java render )
4 : Application Server
App Webapp (Java interaction)
Others WebApps
5 : Database Server
Oracle, SQL, MySQL
6 : Data