Summary of messaging API
The SwitchYard messaging API is clear and works really well with present bus implementations (local and camel). The main problem I do see now is relation between in/out context and messages. In general - the ide of having just one message for exchange is really pure. The message which remains in Exchange goes straight forward to consumer, when we have IN-OUT pattern set. I wouldn't change this at all. One thing which makes me afraid is lack of relation between message and context properties, even in case when message have headers. In fact our components extract all the time headers from inbound messages like SOAP/JMS/HTTP headers and put them into SwitchYard exchange context and map them back to outbound messages.
I experienced few places where components heavily rely on very specific behaviour - that everything in context is keep during the mediation. That's why we have exchange scope, it's not so good when we talk about IN scope available during sending response. The initiator of communication who initialize exchange (gateway let say) have copy of initial message. When he receives response with another message he can check. Initiator will have access to both. If I see things correctly (please correct me if I don't), only one place where we basically have two messages is service provider. But provider is the place where second (outgoing) message is usually created. If provider is not called then we had fault thrown before, because inbound message was incorrect. After calling provider inbound message dissapear and we have only outgoing message. We still keep IN properties, I would say - "just in case" when somebody would like to use them.
Unit tests
The places where IN and OUT properties are used at the same time are tests. However, even with some tests marked as ignored quickstart tests fails. The tests I had to disable now:
- org.switchyard.component.bpm.work.BPMWorkTest
- testReuseHandler
- testReuseHandler
- testRulesFired
- org.switchyard.component.soap.SOAPGatewayTest
- invokeRequestResponseFault
- invokeRequestResponseCustomFault
- invokeCustomFaultWithDetails
- org.switchyard.component.http.HttpGatewayTest - it was failing but after placing few additional if conditions in camel exchange bus works
The additional if conditions were necessary because of constructions like this:
exchange.getContext().setProperty("someProp", "xyz", Scope.OUT);
exchange.send(exchange.createMessage());
What happens from camel point of view - we placed header "someProp" in message already attached to camel exchange and send some else with no headers since create message returns new message instance. This is not anybody fault. It's because differences in API. Am I afraid that we will have big troubles with keeping both working well together. Even if we think about changes I've made in terms of SwitchYard 2.0 and Camel 3.0 I don't expect that message headers will go out in Camel 3.0 and "hole" between APIs will remain. As said before, it's de facto how messages in 70% of cases looks like (HTTP/REST, SOAP, JMS).
The problem of "message rolling" in Camel (it's my name for this behavior) that OUT message from one processor becomes IN message for another hits really only Provider and Consumer callback processor and can be easily walked around by keeping copy of camel exchange in message attached to exchange.
Future moves
If we would like to get SwitchYard exchange mapped to Camel Exchange in 1.x release we have following options:
- Force particular order of calls on exchange:
- first create message
- then set properties
- send message
- Change IN and OUT scope to MESSAGE scope
The second option is more complicated, however it have big benefit compared to first one. User implementing own handler will never do mistake, or will make it much more intentionally. Whats your thoughts about that?
