6 Replies Latest reply: May 18, 2012 4:36 AM by Ivo Bek RSS

SWITCHYARD-710, 703 and Context Property labels

David Ward Master

So I've got work completed for SWITCHYARD-710, which is a prerequisite for SWITCHYARD-703.  There are a handful of changes, all of which warrant explanation, but the last of which (#4) might require discussion:

 

  1. A new enumeration exists for the purpose of configuring the SOAPContextMapper. It is called SOAPHeadersType, and contains the values CONFIG, VALUE, DOM and XML.  If in the <soap.binding> configuration element, you have a child <contextMapper> element, you can now specifiy a soapHeadersType attribute (again with values "CONFIG, "VALUE", "DOM" or "XML").  The default is VALUE, and the text content value of the soap header will be used for the context property value.  However, if you specify DOM, then the entire DOM object representing that soap header element will be stored as the context property value.  If you specify XML, the XML String representation of the soap header element is used, and if you specify CONFIG an org.switchyard.config.Configuration object is used (this could be desirable since it's API is much easier than DOM's API).
  2. To support #1, the schemas for the soap, camel and hornetq bindings had to change, since the soapHeadersType attribute only makes sense for soap. The benefit is that now each binding has it's own inherited definition of this element, with soap extending it with this additional attribute.
  3. Previously, a hack existed in our core/common module contiaining "ContextMapperInfo" and "MessageComposerInfo" interfaces. This is because the ContextMapper and MessageComposer classes existed in our core/api module, but the model classes existed in core/config, so the "Info" classes were there for compilation visibility. Yuck. So what I've done is removed the "Info" classes from core/common and moved the implementations from core/api into a new module: components/common/composer (right next to components/common/rules). This makes core/api and core/common trimmer and much cleaner, and makes sense to be in components/common/composer since the composer classes are only required by components/soap, components/hornetq and components/camel.
  4. A proposal on this thread was that when extracting SOAPHeaderElements from within the SOAPContextMapper, the context property names used should be prefixed with something like "soapheader_".  I wasn't a big fan of the idea of kludging meta-information inside the name of a property itself, so I came up with the idea of context property labels.  I added the following methods to org.switchyard.Property: getLabels():Set<String>, addLabels(String...):Property, removeLabels(String...):Property, hasLabel(String):boolean.  Labels are trimmed, can never be null, and always stored and compared case-insensitive.  Now Properties can have meta-information about where they originiated from.  Properties from the SOAPContextMapper can have labels "soap_message_header" or "soap_message_mime_header", Properties from CamelContextMapper can have labels "camel_exchange_property" or "camel_message_header", and Properties from HornetQContextMapper can have label "hornetq_message_property".  You can see an example of these labels being set here.  With this change, the code proposed here for resolving SWITCHYARD-704 becomes cleaner and not hardcoded.  Instead of the RiftsawBPELExchangeHandler adding a header if p.getName().startsWith("soapheader_"), it can add it if p.hasLabel(SOAPComposition.SOAP_MESSAGE_HEADER).

 

Comments/criticism welcome.

  • 1. Re: SWITCHYARD-710, 703 and Context Property labels
    Ivo Bek Newbie

    Great work David, Thank you

  • 2. Re: SWITCHYARD-710, 703 and Context Property labels
    David Ward Master

    You're welcome, Ivo.  I've just issued the necessary pull requests for SWITCHYARD-710 (listed on the jira itself).  Hopefully you will be able to complete SWITCHYARD-703 easily using my changes once those get processed.

  • 3. Re: SWITCHYARD-710, 703 and Context Property labels
    Keith Babo Master

     

    1. A new enumeration exists for the purpose of configuring the SOAPContextMapper. It is called SOAPHeadersType, and contains the values CONFIG, VALUE, DOM and XML.  If in the <soap.binding> configuration element, you have a child <contextMapper> element, you can now specifiy a soapHeadersType attribute (again with values "CONFIG, "VALUE", "DOM" or "XML").  The default is VALUE, and the text content value of the soap header will be used for the context property value.  However, if you specify DOM, then the entire DOM object representing that soap header element will be stored as the context property value.  If you specify XML, the XML String representation of the soap header element is used, and if you specify CONFIG an org.switchyard.config.Configuration object is used (this could be desirable since it's API is much easier than DOM's API).

     

     

    I didn't dig enough to find the answer, so I'll just ask - is it possible with this approach to get all the SOAP headers mapped as a single document fragment / node into a context property?  If not, might be worth considering as an enhancement.

     

    2. To support #1, the schemas for the soap, camel and hornetq bindings had to change, since the soapHeadersType attribute only makes sense for soap. The benefit is that now each binding has it's own inherited definition of this element, with soap extending it with this additional attribute.

     

    Only comment I have here is that XML header/property manipulation is likely to cross into other encodings beyond just SOAP.  So it seems like at some point we may want to generalize this beyond just the SOAP gateway so that other components can use it as well.  That said, I think the current implementation is good because SOAP will be the most common use case and I would prefer to hammer on this and work out issues before generalizing it.

     

     

    3. Previously, a hack existed in our core/common module contiaining "ContextMapperInfo" and "MessageComposerInfo" interfaces. This is because the ContextMapper and MessageComposer classes existed in our core/api module, but the model classes existed in core/config, so the "Info" classes were there for compilation visibility. Yuck. So what I've done is removed the "Info" classes from core/common and moved the implementations from core/api into a new module: components/common/composer (right next to components/common/rules). This makes core/api and core/common trimmer and much cleaner, and makes sense to be in components/common/composer since the composer classes are only required by components/soap, components/hornetq and components/camel.

     

    You complete me.

     

     

     

    4. A proposal on this thread was that when extracting SOAPHeaderElements from within the SOAPContextMapper, the context property names used should be prefixed with something like "soapheader_".  I wasn't a big fan of the idea of kludging meta-information inside the name of a property itself, so I came up with the idea of context property labels.  I added the following methods to org.switchyard.Property: getLabels():Set<String>, addLabels(String...):Property, removeLabels(String...):Property, hasLabel(String):boolean.  Labels are trimmed, can never be null, and always stored and compared case-insensitive.  Now Properties can have meta-information about where they originiated from.  Properties from the SOAPContextMapper can have labels "soap_message_header" or "soap_message_mime_header", Properties from CamelContextMapper can have labels "camel_exchange_property" or "camel_message_header", and Properties from HornetQContextMapper can have label "hornetq_message_property".  You can see an example of these labels being set here.  With this change, the code proposed here for resolving SWITCHYARD-704 becomes cleaner and not hardcoded.  Instead of the RiftsawBPELExchangeHandler adding a header if p.getName().startsWith("soapheader_"), it can add it if p.hasLabel(SOAPComposition.SOAP_MESSAGE_HEADER).

     

     

    This is an interesting approach.  I say we run with it and see where it gets us.  I like the idea of a label gathering properties in an unobtrusive way.  So instead of having lots of little buckets for properties, we have one big bucket and a way to separate them based on label.  One potential drawback of this approach is naming collision.  A common property name like "message-id" or "timesamp" can be overwritten.  Now, the whole concept of scopes might be enough to box this in (IN scope properties should not move automatically to OUT, exchange scope properties should not move between exchanges, etc.), but I have a feeling this will come up a few times before we nail it down.

     

    Let's see how far we can get this solution.  First test will be to see how Ivo's work comes along. :-)

     

     

     

    Comments/criticism welcome.

     

    You need to walk away from "import static" for good.  Hey, you asked!  ;-)

  • 4. Re: SWITCHYARD-710, 703 and Context Property labels
    David Ward Master
    1. Nope. Different context property per Node. Please add a jira if you want the enhancement you mentioned, but I seriously doubt it will be a 0.5 thing.
    2. I agree that this goes beyond SOAP (and I talked about that in the jira even), but I say let's bang on this for a while before we try to figure out the best way to generalize it.
    3. Awww...
    4. I got the "labels" idea from how gmail uses labels instead of folders. I agree we should let this run for a while before thinking we need to change it.
  • 5. Re: SWITCHYARD-710, 703 and Context Property labels
    David Ward Master

    Ivo,

     

    Okay, SWITCHYARD-710 has been pushed to master (in the varios repos).  Can you please give SWITCHYARD-703 another shot with the changes and let me know how it goes?

     

    Thanks,

    David

  • 6. Re: SWITCHYARD-710, 703 and Context Property labels
    Ivo Bek Newbie

    David, perfect so I download the SwitchYard snapshot from jenkins and after I will change the current implementation I use now, I will let you know.