We Keep Coding

What is main purpose of interface for Service and DAO in spring framework?

I am new for spring framework. I have searched many website for spring mvc on google and i have noticed that created interface for every service and dao but i have some queries as below :
1) What is the main purpose to create interface for every service and dao?
2) How should be project structure for spring mvc?

What is the purpose of interface
Short answer: dependency injection
Long answer: You see, we do not want concrete implementation and strong coupling in our application. Interfaces serves that purpose, with or without Spring. Spring is a framework that heavily leverages on that. With an interface, you can write multiple implementations of a single logic by defining a contract (interface methods) that describes what is the parameter and return types but you did not specify how is it done. Which gives you a lot of flexibility in writing different Spring beans (Impl classes) that do that. List in Java is an interface, then you have implementations like LinkedList and ArrayList
How should Spring MVC project be structured
Short answer: anyway you like
Long answer: Are you using Spring MVC as API server or serving views like JSP/Thymeleaf? If I am writing an API I would have Controllers (entry point and spring specific features), Facades (business logic that is pure Java without framework classes), and DAO/Services (depending if data comes from database or 3rd party API, maybe both) at bare minimum. For MVC I would have almost similar setups but depending on your agreement with your API provider I might scrap the service layer and focuses more on the Javascript side. In this day and age I'd advise against using JSP/Freemarker. They are a lot slower to develop compared to having let's say React + API server in any language.

spring restful dto or entity

I am developing a spring restful application that uses hibernate. I am coming across scenarios where i had to place jackson json annotations on entity getters. Ex: One to Many mappings.
Is it a good idea to place jackson json annotations on hibernate entities? Or should i go with DTO pattern to pass data that is just needed by UI? I may end up creating a DTO for every entity.
Below is the application architecture. Common is at root level. DAO has dependency on Common and so on.
Common <- DAO <- Services <- Web
DAO has entities
Services or Web can have DTO's
Please let me know your thoughts or suggestions.

Disclaimer: I am speaking from opinion and experience here
Separate dto and entities are common practice. What you choose to do really depends on it's use. One of the drawbacks of adding DTO annotations on your data model entities is versioning. Versioning becomes hard when your data model is tied to your contract. If your webservice is only used by a consumer you own and its deploy schedule is the same then it's probably not worth separating dto/entities. If you don't need versioning and you mostly have CRUD web services then you may want to look into spring data rest.
If you arn't so lucky, and have multiple consumers, then you may want to think through a few version breaking changes and how you will handle it. This will help you see the value in separating the data and contract.

How does Spring Data (JPA) relate to JPA persistence providers?

I'm trying to wrap my head around JPA and have learned quite a bit. JPA is a java specification and providers implement this spec. I Understand that part.
What I don't understand is how Spring Data comes into the picture. Is Spring Data also a provider like Hibernate or OpenJPA? If not, what is it? How does Spring Data "make things easier"?

The Spring Data project in general is an umbrella project with the following mission statement:
… provide a familiar and consistent Spring-based programming model while retaining store-specific features and capabilities.
So we approach the persistence space in general not only relational data access through JPA. The important piece here is two fold:
Programming model instead of generic API
Support for store specific features
As the data access space is so diverse these days, trying to approach all of the stores with a single unifying API is doomed to fail. You'd end up with a least common denominator that hides away the store specific parts - in times where you selectively choose a particular store because of it's specifics. Abstracting those away totally subverts this. Especially trying to use JPA is wrong in our opinion as it's deeply tied to relational concepts (#Table, joins, transactions) by definition.
Still, you don't want to work with completely different APIs, don't wanna be lost in store differences if you work with multiple ones or switch from one project to another. Spring has traditionally helped in that regard by embracing a consistent programming model, that features abstractions that work the same way but are still specific to a particular technology. For example, JDBC and JMS are completely different technologies. Spring offers both a JdbcTemplate as well as a JmsTemplate that cover the same responsibilities (resource management and exception translation) and lower the learning curve when moving from working with JDBC to JMS or vice versa.
Spring Data picks up on that by exposing store-specific functionality through abstractions that Spring developers know. I already mentioned the template, but that also includes general configuration mechanisms (XML namespaces, using DI and AOP etc.).
Repositories
The very top layer of this programming model is the repository abstraction. In its core, it significantly simplifies the development of data access layers by letting you avoid to write more implementation code than strictly necessary. It provides CRUD functionality out of the box, pagination as well as declarative query methods.
Assume a Customer domain class. Enabling persistence for it is just a matter of declaring a repository interface like this:
interface CustomerRepository extends PagingAndSortingRepository<Customer, Long> {
List<Customer> findByLastnameContaining(String lastname);
}
Now it's a matter of configuration (and domain class mapping) to be able to create an instance of this interface and use it from a client. PagingAndSortingRepository includes basic CRUD functionality as well as stuff like Page<Customer> findAll(Pageable pageable) (so page-by-page access). As you can see, we also support a query derivation mechanism to avoid needing to write any implementation code for simply queries. For more complex ones, we allow the manual declaration (e.g. using #Query on the method) or even the manual implementation if necessary.
A neat side-effect here is, that by a flip-switch in the configuration you could use the same repository interface to persist Customer instances into a MongoDB. That doesn't mean we recommend to blindly move from one store to another as the stores usually require the data model to be adapted to work efficiently. However it allows developers to quickly switch between projects working with different stores as the repositories just work the same way (implementing the programming model over common API approach).
JPA specifics
Spring Data JPA is actually a thin layer implementing the repository abstraction plus a few other bells and whistles. So we're not replacing persistence providers but actually leverage them through the API, even mitigating some of the quirks and differences between individual JPA providers.

Think of Spring Data as a way to support JPA and many other persistence models in a manner that is transparent to your own code. Spring Data makes it easier for you to manipulate more types of data source systems in a unified interface. Without Spring Data, you would need to introduce more adapters in your code, each time you would have to deal with extra logic.

spring-data JPA is not a JPA provider. It is a library / framework that adds an extra layer of abstraction on the top of our JPA provider(Hibernate/TopLink). If you are using Spring Data in your project, you are not going to write most of the low level data access operations like writing SQL query, DAO classes etc.
But you must have a JPA-Provider (Hibernate, Toplink etc) to implement spring-data-jpa.

Is DTO pattern deprecated or not?

In a complete Java EE application that's clustered is the DTO pattern still a valid option? The application in question uses EJBs Hibernate and Struts with Spring etc. Is there anything wrong with transferring domain objects in such a scenario?
EDIT: Just to clarify my question, with modern day resources and improvements in Java EE is there a reason not to just use domain objects? If there is not then isn't DTO pattern sort of fading out and shouldn't be used in new applications?

Is not deprecated. It depends on the application architecture if the DTO pattern should be used or not. For example, when you develop Web Services (using JAX-WS or JAX-RS), you should send DTO's over your web methods so a C# or Python client application may consume it, and your web method should not return an object which class has Hibernate annotations, remember than in other languages the Entity won´t be created with those annotations or other business logic inside.
EDIT (Based in your comment): That depends on the software architecture. For example, I'm working on a SOA project and we use DTO's for the Services Layer and the Presentation Layer. More deeper inside, we even use DTO's to handle database communication inside the services, we use only SP's to communicate with DB, so no Hibernate or any other ORM tools can work there, we could use Spring DAO and that framework uses DTO's too. You can find lots of DTO pattern in many applications nowadays.
More info that would be great for this question:
Difference between DTO, VO, POJO, JavaBeans? (where basically, any DTO is a POJO).
Core J2EE Patterns - Transfer Object
EDIT 2: Another source of information that will explain the main reason for using DTO's design, explained by Martin Fowler
LocalDTO
Conclusion: DTO's are not an anti pattern. DTO's are meant to be used only when you need to pass data from one subsystem to another and they don't have a default or standar way to communicate.

It is a very useful pattern in Java EE.
I use a DTO to transfer related entity objects from EJB beans to the UI layer. The entity objects are fetched from DB in one transaction (see TransactionAttributeType.REQUIRED) and stored in the DTO object. The DTO is consumed in the UI layer.

A pattern is pure design. There is no "deprecation" of pattern, but less usage over time (or over-usage).
Personally, I don't see why not to use DTOs.
For example - at oVirt open source project we have entities representing business logic entities in the domain of Virtualization.
These entities should be either annotated by Hibernate annotations (actually, they are today, as we started working on hibernate POCs) and serve as the DTOs , and then have clean from annotations objects that will mapped to them (let's say, using dozer framework) and used by client
(I don't like have at client side code with unnecessary annotations), or the entities should serve as the client objects (value objects) passed to the client and we should have other classes serve as the DTO entities
The minus in the above approach is that you might have 2 parallel class diagrams - one for DTOs and one for value objects (that are used by clients) - but , in many cases in design , there is a trade-off.
You must understand the advantages and disadvantages and pick what is best for you (In our case, since the client side is GWT, it will be easier for us to go for separation to two class hierarchies, one that is DTO/server side and can be also annotated with more server side only annotations, and the other sent to the GWT client code).

How should my business objects be set up with a Spring/Hibernate project

I'm setting up a Spring 3/Hibernate 3.6 application architecture for the first time and have all of the parts configured but need more information about the proper architecture design for a business layer. Please provide advice or links to resources that will suggest the appropriate setup for a separate business layer between my controllers and DAOs. Are there any suggested technologies for business objects or are POJOs normally used? Is the application simply divided with a separate folder, on the same level as my controllers, for business objects?

It depends on the size of your application, what your business objects do and how they depend on each other.
Typically the business objects will reside in one or more folders/packages depending on
functionality, and
their inter-dependence on each other
POJOs will normally do the job specially when you have Spring to take care of the transactionality and other cross cutting concerns.
I have also seen designs of very large applications where the services layer and DAOs are separated out into different applications for more loose coupling. So it really depends on various factors how you lay out the application structure.

Use the business layer to annotate & define your transaction contexts (Transaction Control).
You can package it as per you functional requirements. No set rule.
You can use simple java objects as long as you clearly separate your concerns.
Ensure that you do not use hibernate/db specific APIs in your business/service objects.
Use annotations on your POJOs to define relationships/mappings.