One issue causing confusion about whether to choose a repository or a service is where to put business logic methods like getEntityItemBySomeAttribute(attribute).
The use of Specifications in a standard query method seems to solve this problem.
Where you would want to choose the Service instead is when the logic of the query spans multiple repositories or a combination of repositories and external services -- this is DDD guidance.
Be mindful of the difference between APIs and SPIs. APIs should be final concrete classes and SPIs should be Interfaces. The clients of APIs are callers while the clients of SPIs are implementers.
I've noticed that repositories are typically SPIs while services are typically APIs.
Refs:
http://wiki.apidesign.org/index.php?title=APIvsSPI&useskin=monobook
https://docs.oracle.com/javase/tutorial/ext/basics/spi.html
http://stackoverflow.com/questions/12317126/onion-architecture-repository-vs-service
http://thinkinginobjects.com/2012/08/26/dont-use-dao-use-repository/ -- notes that DAOs are no longer favored because they are too general and loosely typed.
-------
2015-09-03
Current common practice appears to have a topology like Service<T> --injected with--> Repository<T> --injected with--> JDBCTemplate or DataSource. see http://stackoverflow.com/a/24083073/2066936
