Camel routes can be used as services in SwitchYard, so it's not really a decision between one or the other. SwitchYard itself leverages Camel heavily, so the two really go hand in hand if you are considering using SwitchYard.
Thanks for that answer.
So if I have a camel route, what would be example business requirements that would induce me to want to or to have to wrap it in a Switchyard service as opposed than letting it run independent? I.e. what use cases is a Switchyard service solving that a pure Camel implementation is not?
SwitchYard is basically a framework for creating service-oriented applications using a structured development process. From a "business requirements" standpoint, this probably boils down to whether your requirements include things like SOA, governance, compatibility with other platform technologies (Java EE, BPEL, BPMN 2, rules), application server integration, etc. These are not things that Camel can't do on its own. Think of SwitchYard as a framework which layers on top of Camel and provides these things out of the box.
Here's a talk I gave at CamelOne last year which addresses many of these points:
These are not things that Camel can't do on its own.
Just to clarify, this was a deliberate double negative. To state it a different way, you can certainly use Camel to do these things, it's just not something that Camel addresses directly on its own. With the right development process and discipline, you can craft Camel applications that clearly describe dependencies, abstract binding details from your service logic, eliminate data coupling between services, etc, etc. In fact, the presentation I linked lists examples of doing all of that with Camel directly. SwitchYard is a higher-level framework which can be used with Camel to bake all of these things directly into your development process and application model.