I'm sure this will be made clear once you have some code ready, but to me there are basically two different representations of a message today:
1) The native representation of a message as it enters/exits a gateway binding from/to the outside world.
2) The internal, normalized representation of a message (our SwitchYard API for Message and Context).
The context mapper and message composer are user-customizable extension points for handling the mapping from native to normalized message and vice versa. In many cases, it makes sense to have a wrapper object used in the composer to capture multiple elements of the native message. What's not clear to me is what commonality there will be across native composers/mappers. My expectation would be that the commonality is found in the normalized representations (e.g. well-known slots for security credentials).
My expectation would be that the commonality is found in the normalized representations (e.g. well-known slots for security credentials).
To be clear, the "wrapper" type is to wrap the native representations only, and provide well-known accessors, like to security credentials as you mentioned. In fact, that's all I'm currently aiming for in this initial iteration.