I don't disagree with netzooid's conclusions:
Please keep in mind that REST and SOAP programming models don’t mix well. There is this complete fallacy going around (I succumbed to it too at one point) that you can use the same service class or description to build a RESTful and a SOAP based service. However, the interactions and mappings should end up being completely different from one to the other! One is message based and one is resource based. You’re going to have to design your service differently as they’re two completely different beasts.I largely agree with this. What I will say is that if you've already got a REST or a SOAP API and you have the capability to expose that API through the other technology, it's often possible to do so. While this might not truly be a REST or SOAP api, it's close enough for many people.
That said, the natural approach for REST and the natural approach for SOAP are quite different, and to do a good job of both, you'll find that your services end up being quite different, even if they're layered on top of the same basic infrastructure.
I've used Restlet, and I'm relatively happy with it. It's still maturing, but it's basically ready-to-go. I've been watching Jersey interestedly, and it seems to be shaping up well, but there's always time for the JCP to mess it all up before a final release. I've also used Enunciate, which is capable of generating both SOAP and REST. It's an interesting concept, although I do believe it needs more time to be mature enough to recommend.