Your first question is covered by this one. To summarize, there are descriptor files present for JAX-RPC, since it uses XML mapping documents to describe reflection-based rules for marshal/unmarshal.
As for your second question, I suggest writing the same HelloService web service (provider) using both frameworks. I think you'll find JAX-WS much easier, if for no other reason than finding tutorial documentation. Use two web modules and follow tutorials to create the same functionality.
Take a look at the artifacts for both. Also experiment with adding complex Java types as input or output. Notice that JAX-RPC cannot automatically convert many WSDL/schema constructs to a Java equivalent - a great side by side comparison article (and series) is here.
A personal anecdote - due to the JAXB underpinnings, the JAX-WS service will be much more forgiving if the request message has small deviations from the WSDL such as unexpected input elements, etc. Why is this important? Versioning & maintenance. With JAX-RPC, it was much more difficult to update the service provider with new fields without breaking JAX-RPC client applications, and vice versa.
Spec Time
I've seen it mentioned that JAX-RPC is deprecated as of JavaEE 6. I don't see that wording specifically (it is listed for server implementors as "proposed optional"; the PDF spec says the following:
EE.12.2.3
JAX-WS JAX-WS, along with JAXB and the Metadata for Web
Services specification, provides simpler and more complete support for
web services than is available using the JAX-RPC technology.
Applications that provide web services using JAX-RPC should consider
migrating to the JAX-WS API.
(emphasis mine).
The JavaEE 7 spec lists JAX-RPC not only as optional (for server implementors); it also includes it in the list of "pruned Java technologies" - candidates for outright removal in subsequent JavaEE spec versions.
All this to say: you don't earn your way out of the JavaEE specification if you're the better spec.