Currently servicemix JMSFlow transports Messages between Service endpoints as serialized objects. More exactly the serialized version of the servicemix MessageExchange implementation object is used.
The disadvantage is that this is no standard format. So only servicemix containers can talk to each other using JMSFlow. This is the reason why we did not use JMSFlow in our project to connect containers and instead used JMS endpoints. This allows us to use for example Tibco Business Works or Even .Net3 on the other end of the queue. But the problem is that creating a SU and a JMS endpoint for each service is quite a lot of redundant configuration.
If JMSFlow would use the same Messages as a JMS Endpoint and use a canonical queue name derived from the namespace and endpoint name we could have the best of both worlds. We only have to configure the service units and have full compatibility with other containers.
Another way to achieve the same effect would be a binding component that creates a jms endpoint and a queue for each service unit on the fly.
In any case what I would like to see is that you simply write and deploy service units and have them on an open service bus instantly. Binding components would then only be used for optional additional bindings like SOAP/HTTP or proprietary bindings.