-
1. Re: Extensible "wrapper" type for Message Composition
dward Aug 28, 2012 2:40 PM (in response to dward)jira created: SWITCHYARD-1003
-
2. Re: Extensible "wrapper" type for Message Composition
kcbabo Aug 28, 2012 2:57 PM (in response to dward)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).
-
3. Re: Extensible "wrapper" type for Message Composition
dward Aug 28, 2012 3:08 PM (in response to kcbabo)My expectation would be that the commonality is found in the normalized representations (e.g. well-known slots for security credentials).
Correct.
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.