3 Replies Latest reply on Aug 28, 2012 3:08 PM by David Ward

    Extensible "wrapper" type for Message Composition

    David Ward Master

      MessageComposers and ContextMappers have a generic type associated with them, which is the type of native message that binding/gateway is associated with.  For some components, there is an easy candidate, for example: SOAPMessage for the soap component. For others, we had to "invent" one, for example: RESTEasyMessage. This invented message type is a wrapper/holder for the data that the resteasy component's MessageComposer and ContextMapper need to chew on.

       

      I suggest we ALWAYS have an "invented" object wrapper, conforming to an interface in component/common (composer pkg).  The reason is twofold:

      1. We need to centralize the abstraction for dealing with security information during composition/context property mapping. This has become a requirement for SWITCHYARD-830.
      2. We need the extensibility to be able to add more "stuff" into the wrapper objects when determined necessary.  For example, not everything the soap component needs is in SOAPMessage.  We also need the WebServiceContext.  Having our own "wrapper" object allows us to hold both pieces of information.

       

      I will be creating a jira for this shortly.

        • 2. Re: Extensible "wrapper" type for Message Composition
          Keith Babo Master

          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
            David Ward Master

            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.