Custom message composer or adding a context property are the two options for getting it done now in SY.  Specifying properties in the switchyard.xml is a legit use case and it's something we need to do for multiple bindings.  I think the best way to do it would be to enhance the default schema for context mappers to allow for value mapping via constants.  That way, the same mechanism works for HTTP, SOAP, JMS, etc., etc.  If this sounds reasonable, feel free to file a JIRA.

thanks,

keith

Hey all,

I'm taking a look at adding a declarative way for specifying message properties within switchyard.xml.  The linked JIRA proposes adding these to the contextMapper element associated with a binding definition.  I think this makes good sense.

Regarding the properties, is there a need to specify properties specific to the inbound message, outbound message and context?  Or is this overkill?

Internally, there is a mechanism for attaching labels to the properties and some binding types adjust their behavior based on the label associated with the property (e.g. SOAP applies properties labeled as HTTP to the MIME header as opposed to the SOAP header).  Given that, should we allow the user to specify labels for each property when declaring them?  (I assume these would be defaulted to whatever is sensible for the binding type to which they're applied.)

Putting all of that together might yield a structure like:

<contextMapper>
  <in>
    <property name="propertyName" labels="component.soap endpoint.http">propertyValue</property>
  </in>
  <out>
    <property name="propertyName" labels="component.soap endpoint.http">propertyValue</property>
  </out>
  <context>
    <property name="propertyName" labels="component.soap endpoint.http">propertyValue</property>
  </context>
</contextMapper>

Opinions?

Thanks in advance,

Rob

I've started sketching out the basic functionality as well as how it might look when integrated into a component binding.  The changes can be found in the following branches:

• core - https://github.com/rcernich/core/tree/SWITCHYARD-1618
• components - https://github.com/rcernich/components/tree/SWITCHYARD-1618

The schema changes for contextMapper can be found at [1].  These changes are similar to what is described in the previous post, with the exception that "context" has been renamed "exchange."

The properties are injected via the context mapper, as illustrated by the following (for Camel bindings) at, [2-5].  This means that "in" properties will be associated with the message entering through the binding and "out" properties will be associated with the message exiting through the binding.  This implies that "in" properties will be associated with the "in" message for service bindings, but the "out" message for reference bindings (as the message entering the binding is the response).

Regarding labels, if no labels are specified in the configuration, the default labels for the binding are applied to the properties.  Labels are specified using a simplified <type>.<name> syntax (e.g. component.soap, behavior.transient, etc.).

Opinions?

Rob

[1] https://github.com/rcernich/core/blob/SWITCHYARD-1618/config/src/main/resources/org/switchyard/config/model/switchyard/v1/switchyard-v1.xsd#L45-47

[2] https://github.com/rcernich/components/blob/SWITCHYARD-1618/common/camel/src/main/java/org/switchyard/component/camel/common/composer/CamelContextMapper.java#L68

[3] https://github.com/rcernich/components/blob/SWITCHYARD-1618/common/camel/src/main/java/org/switchyard/component/camel/common/composer/CamelContextMapper.java#L79

[4] https://github.com/rcernich/components/blob/SWITCHYARD-1618/common/camel/src/main/java/org/switchyard/component/camel/common/composer/CamelContextMapper.java#L100

[5] https://github.com/rcernich/components/blob/SWITCHYARD-1618/common/camel/src/main/java/org/switchyard/component/camel/common/composer/CamelContextMapper.java#L111

Hey Tadayoshi,

 

1. My understanding is that, say, in a SOAP reference binding, if you declare both "in" and "out" properties in the contextMapper, "in" properties result in SOAP request headers and "out" result in response headers respectively in one request-response conversation (given the default label). Is that correct?

No.  That is the way it would behave for a service binding.  For a reference binding it would be the opposite: out properties would be applied to the request; in properties to the response.

 

2. Is the Properties substitution effective also in the "propertyValue" part?

Yes, substitutions will apply.

Best,

Rob

This looks cool.  A few comments after looking at the examples/code:

• I think the name should be "property", not "header" in the schema.
• Having out represent the request message for outbound and response message for inbound isn't consistent with IN and OUT as they are used with ExchangePhase.  I understand that the message is actually moving "out" of the system, but even so that's the in phase of the MEP.
• I don't think any labels should be added by default.  Providing the option to specify labels is good though.  With that in mind, you may have done this because some components won't pull context properties that don't have a label, in which case that's something we need to discuss. :-)
• Instead of having a protected() method that's explicitly called from context mappers, can we just call super.mapFrom() and super.MapTo() ?
• I have a feeling we will get requests to resolve/evaluate vars in addition to supporting literal values as we have today.  Not sure if that would just be an extra attribute on the property element or what.

Thanks for making it easy to review with all the links.

Hey Keith,

Thanks for taking the time to review.

I went with "header" as opposed to "property" because property is already defined in the SwitchYard schema.  That said, I don't mind changing the name to something else.

As for the MEP, I just took the easy way out.  I'll look to see if I can determine the phase and act accordingly.

As for the labels, I was simply going with how the specific context mappers already applied them.  In the case of Camel, it adds those labels already, so I considered that to be "default" for this particular case.

super.map*() works for me.  I figured I would need to modify every specialized version anyway, so I went with what was most flexible.  I'll move what's there now into the base implementation.  I may leave the existing helper method in as well, but I'll know for sure whether or not it needs to be exposed after updating all the component specific context mappers.

Regarding variable evaluation, would that be different than using ${variable:default} notation?  If this is not wired in correctly, then I'll get that hooked up.  If you meant something different, then I just need clarification on what that means.

Thanks again,

Rob

What happened to this?

Did it get dropped to get into upstream code?

Was it taken to the upstream?