From my understanding of a service layer I don't know how you would generate that; if written properly it should be very much based on your business model, and shouldn't follow your database schema much at all. Unlike a DAO (arguably, I actually don't have DAO's one to one entity all the time either), you shouldn't have a service for every entity, instead your services should either use entities as part of their API to perform units of work, or supply business objects that are an abstraction layer between the controlling logic and data access. It can also be a hybrid of both. This depends on how complicated the application is, and how closely related your DAO/Entities are to your database.
EDIT: Based on your comment, and the great rush, I would use the tools mentioned in other posts to generate your DAO layer, that will give you a very good start. Then I would create a single Service object that holds all of your DAOs. From there, you will have access to do all your business logic in a testable container (the service object). This will keep you from putting it in the controllers, and will give a single place where people can see all the business logic methods. As it grows you will see the redundancies, and the logical units that you could later seperate into different service objects.
Hopefully you will have the time to do so, but when I'm in a huge rush, I like all of my business complexity to be in a single service object, as opposed to many controllers. The refactoring you do later will be much easier. And you can still easily test methods, which I'd recommend regardless of the rush, trust me, it's faster to write tests on service methods than test them by deploying, and checking.