I managed to cobble together a generic service client, following in the footsteps of the rosbag2 generic subscription and ros2_introspection.
The principles are the same, just using the service type support instead of the message type support. One oddity I did find is that I had to use an rmw-specific typesupport library (rosidl_typesupport_fastrtps_cpp) to get the service typesupport for a given type, which wasn’t necessary for messages.
Agreed - being a bit of a ROS2 novice I was disappointed to find that I needed to duplicate the(de)serialization method used in the specific rmw implementation I was using in order to get usable data out of a SerializedMessage. It feels like something that should be possible without coupling my application to a specific rmw implementation.
It occurs to me that there is another approach to solve the problem of writing generic C++ applications that work with message / service types not known until runtime. That is to follow the path of SOSS and use generated code which is compiled to plugins that are loaded at runtime. As far as I can tell the key advantage of that route is you don’t have to mess around with the sort of serialisation routines I mentioned above, and should be fully insulated from the rmw. But I don’t know if using using SOSS as a library for an existing application one of its intended uses, rather than as a standalone gateway.