I have read many articles on this topic and in the end all I have ended up being is confused.

Some articles say to use Hibernate Business Objects instead. The problem I see here is that you have to assemble the Business objects and this can involve business logic (conditions as to what data needs to go where, when, selects from the db, validation etc). So the Action class doesn't appear to be the place for this. Refactoring all this logic out into the service layer leave you with one of 2 solutions. a) Method signatures of the service methods either have all the parameters necessary to fulfil the requests or b) Method signatures accept DTOs which encapsulate all the parameters necessary to fulfil the requests. So this is contradictory to the "use Hibernate Business Objects instead".

What is the best option for talking to Service Layer? DTO or not.

We ended up using DTOs with our service layer, but only because we needed to serialize the objects into XML SOAP message. In all likelihood you'll probably use bi-directional relationships in your hibernate objects so that causes circular references and thus cause XML serialization to fail.

Essentially, we used the Hibernate BOs throughout or Java EJB layer, but resorted to DTOs for the service layer. Are DTOs were basically our BOs minus the circular references.

HTH,
Lou