ContextMapper Scopes Opinions Requested
dward Nov 23, 2011 4:24 PMIn SwitchYard 0.3, there is the notion of MessageComposers and ContextMappers.
A MessageComposer can compose or decompose a native binding message to/from SwitchYard's canonical message. A MessageComposer does this in threee steps:
- Construct a new target message instance.
- Copy the content ("body") of the message.
- Delegate the header/property mapping to a ContextMapper.
We currently have a SOAPMessageComposer, a CamelMessageComposer, and a HornetQMessageComposer.
A ContextMapper moves native binding message headers and/or properties to/from SwitchYard's canonical message. We currently have a SOAPContextMapper, a CamelContextMapper, and a HornetQContextMapper.
The above are the default implementations, but users can override with their own MessageComposer and/or ContextMapper implmementations by using the <messageComposer/> and <contextMapper/> elements in their <binding.xxx/> section(s) of their switchyard.xml.
This discussion thread is focused on the out-of-the-box behavior of the default ContextMapper implementations we provide in 0.3:
- A SOAPContextMapper, when processing an incoming SOAPMessage, takes the mime (in most cases, HTTP) headers from a soap envelope and maps them into the SwitchYard Context as Scope.IN properties, and takes the soap headers from the soap envelope and maps them into the SwitchYard Context as Scope.EXCHANGE properties. When processing an outgoing SOAPMessage, it takes the SwitchYard Scope.OUT Context properties and maps them into mime (in most cases, HTTP) headers, and takes the SwitchYard Scope.EXCHANGE Context properties and maps them into the soap envelope as soap headers.
- A CamelContextMapper, when processing an incoming CamelMessage, takes the CamelMessage headers and maps them into the SwitchYard Context as Scope.IN properties, and takes the CamelMessage properties and maps them into the SwitchYardContext as Scope.EXCHANGE properties. When processing an outgoing CamelMessage, it takes the SwitchYard Scope.OUT Context properties and maps them into the CamelMessage as headers, and takes the SwitchYard Scope.EXCHANGE Context properties and maps them into the CamelMessage as properties.
- A HornetQContextMapper, when processing an incoming ClientMessage, takes the ClientMessage properties and maps them into the SwitchYardContext as Scope.EXCHANGE properties. When procesing an outgoing ClientMessage, it takes the SwitchYard.EXCHANGE Context properties and maps them into the ClientMessage as properties. There is no concept of "headers" in a HornetQ ClientMessage.
The reasoning of scoping headers as IN and OUT scopes was modeled after the notion of http headers, where you will see some headers specifically useful for http requests, and other headers specifically useful for http responses. In both cases, they are most likely tied to the binding's notion of an incoming message or an outgoing message.
The reasoning of scoping properties as EXCHANGE scope came from the idea that this is most likely application or domain data, and possibly (probably?) useful in the entire processing of the Exchange. An example of this would be a processInstanceId when using the BPM Component.
Is the above behavior what we want by deault? Are there any unwelcome side-effects you can think of? Comments and criticism welcome. Thanks!