So after taking a look at the user guides I am still finding the switchyard approach to Camel/EAI to be a bit counter-intuitive. Switchyard basically treats everything as a "service" whether it is a route/flow, an endpoint or an actual service. This may be optimal in terms of enforcing well defined interfaces and abstracting away details but I think it is too much of a mental hurdle for users working on message driven projects.
Take a look for example at Mule's definition of a Flow, this is more in line with what I expected the Camel integration to look like, a way to compose/orchestrate message flows. From what I understand this is a new concept that they introduced in version 3 to make integration projects both simpler and more flexible. Now don't get me wrong, I understand that you guys want to develop a technically superior solution, I am just concerned about the point to which usability will be impacted.
Here are some questions I have hit upon with the current approach
1) How does a Camel service with multiple route definitions ("from" statements) work? According to the docs
Does the RouteBuilder in Switchyard restrict you to one from? If not how do you link the froms and the bindings?
2) Do Switchyard transforms work within camel routes? The fact that the camel route is defined as a service make me unsure.
3) Is it necessary to define an interface with an "acceptMessage()" method for all camel routes?
I am wondering if the use of the Service Component Architecture model may be making things to complex for EAI use cases. Perhaps SCA could be used to address the services part while allowing a more natural/flexible approach (Camel DSLs) for message routing/orchestration. The two could still be designed to work well together and the best practice could be to wrap all endpoints with a service, but it wouldn't necessarily be the only way.
Here is the earlier Camel Integration thread for reference