Centralize property labels for easier sharing?

[dward]

Right now, we have the following constants that are used as Context Property labels:

• switchyard-component-camel-0.5.0-SNAPSHOT.jar
  • org.switchyard.component.camel.composer.CamelComposition
    • CAMEL_EXCHANGE_PROPERTY = "camel_exchange_property";
    • CAMEL_MESSAGE_HEADER = "camel_message_header";
• switchyard-component-hornetq-0.5.0-SNAPSHOT.jar
  • org.switchyard.component.hornetq.composer.HornetQComposition
    • HORNETQ_MESSAGE_PROPERTY = "hornetq_message_property";
• switchyard-component-jca-0.5.0-SNAPSHOT.jar
  • org.switchyard.component.jca.composer.JCAComposition
    • JCA_MESSAGE_PROPERTY = "jca_message_property";
• switchyard-component-soap-0.5.0-SNAPSHOT.jar
  • org.switchyard.component.soap.composer.SOAPComposition
    • SOAP_MESSAGE_HEADER = "soap_message_header";
    • SOAP_MESSAGE_MIME_HEADER = "soap_message_mime_header";

The problem is that sometimes, in the case of soap <-> riftsaw, labels need to be shared.  We don't want a dependency between component jars, so maybe we should just centralize all labels into a single constants class like so?

• switchyard-component-common-composer-0.6.0-SNAPSHOT.jar
  • org.switchyard.component.common.composer.Labels
    • CAMEL_EXCHANGE_PROPERTY = "camel_exchange_property";
    • CAMEL_MESSAGE_HEADER = "camel_message_header";
    • HORNETQ_MESSAGE_PROPERTY = "hornetq_message_property";
    • JCA_MESSAGE_PROPERTY = "jca_message_property";
    • SOAP_MESSAGE_HEADER = "soap_message_header";
    • SOAP_MESSAGE_MIME_HEADER = "soap_message_mime_header";

Not sure if the class should be "Labels" or "ContextPropertyLabels" or "CompositionConstants" or...

Also not sure if the values for the labels themselves should start with org.switchyard...............

Discuss.

[dward]

Aside, I find it interesting that the bpel component doesn't have a composer package with it's own Composition/MessageComposer/ContextMapper like the other bindings do. Hmmm....

[mageshbk]

I have a feeling this needs much deeper thought. I am not sure this is right, the way we do these labels, context properties, as of now. The example of soap <-> riftsaw, why should riftsaw be looking for labels of soap? The Message context should be component neutral IMHO. What does riftsaw need the SOAP_MESSAGE_HEADER for? As a matter of fact, why should any component need to know through which component it received the message or it's context? I am puzzled

[kcbabo]

Generally speaking, components should strive to use binding and implementation neutral context properties.  In reality, there are cases where a service developer ends up pulling specific context properties into their implementation (e.g. see user forum thread on accessing file name in bean service).  Multiple components can contribute properties to the context and the idea with labels is to provide a form of a bucket or slice of properties within the context that is specific to a component.  The label is not required and it also doesn't prevent you from looking up the context property by name, so it's really just an extra bit of metadata about a property.

If there's a different/better way of handling this requirement, then we should definitely discuss it. 

[mageshbk]

In reality, there are cases where a service developer ends up pulling specific context properties into their implementation (e.g. see user forum thread on accessing file name in bean service).

Ah, you mean this thread https://community.jboss.org/message/745595. Now I understand such a need exists.

Multiple components can contribute properties to the context and the idea with labels is to provide a form of a bucket or slice of properties within the context that is specific to a component.  The label is not required and it also doesn't prevent you from looking up the context property by name, so it's really just an extra bit of metadata about a property.

True, the properties as such are very specific to a component. Say for example, if there is some SOAP header like a relationship id that needed to be saved in the context, I agree that the component may need to re-use such things back when replying. But a XYZ component wanting to know this seem too far fetched. Then we kind of like are not creating loose coupled services but rather a tight coupling between components that break the Service.

With respect to the user thread above, why would a Service need to know the CamelFileExchangeFile property? So if in future when the pipeline is done via another component say our FTPGateway, wouldn't it break that Service and that has to be re-developed?

[dward]

Just wanted to add that there are use cases where you want to know where properties came from. One example is soap proxying.  In that case, you don't want ALL the properties that have been added via various interactions with the context, but in order to faithfully re-playing the soap request, you just want to be able to get a list of all the properties that came just from soap.  So, iterating over the properties and only grabbing those that have a soap label enables this.