Bottom line is that this is a sorta-bug in the HTTP binding. The message composer for HTTP should check the message type defined for the operation to determine if a Java type is used. If it is, then the HTTP composer should attempt a conversion to the declared content type. Here's an example from the composer used by all Camel bindings:
Can you file a JIRA to have this addressed?
In terms of why this works for you now with bean services and not with bpm - that's a side effect of how the bean implementation maps the message content to operation parameters. The bean component uses getContent(Class<T> type), which forces the conversion from StringReader to String. As I mentioned above, this should really happen earlier in the binding layer since the composite service interface defines a type of String, not StringReader.