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.

I certainly hope that we can make it more intuitive for you through a combination of education and feedback for us to improve where appropriate.  Even from the standpoint of a "message driven project", wouldn't you agree that a definition of the message content is important in enterprise integration projects? We certainly try to make it as easy as possible to provide this definition and even allow for it to fall to a degenerate case such as "string in, string out".  In my experience, ignoring the contract in integration projects provides a false economy - get started fast, pay later in terms of maintainability and extensibility.  Not saying that applies to all projects, natch, but I hope it provides some context in terms of why we encourage a service-oriented approach.

 

1) How does a Camel service with multiple route definitions ("from" statements) work? According to the docs

The "from" endpoint in a Camel service must always equal the service name

 

Does the RouteBuilder in Switchyard restrict you to one from? If not how do you link the froms and the bindings?

One from per service.  Of course, you can have multiple services within an application and not all of them have to be exposed to the outside world via a gateway binding.  It's really up to you in terms of how you modularize your application.

If your intent in defining multiple froms is simply to add additional bindings, that can be done in SwitchYard with a single route definition and multiple gateway bindings to that service.

2) Do Switchyard transforms work within camel routes?  The fact that the camel route is defined as a service make me unsure.

They are not called within Camel, but if a Camel route invokes a SwitchYard service, then that invocation will be eligible for transformation.

 

3) Is it necessary to define an interface with an "acceptMessage()" method for all camel routes?

You don't have to have that method name.  In fact, the method name is really just a way to group messages that move into and out of a service.  You do need an interface though.  In reality, all Camel routes have an interface whether you decide to formalize it or not.  All we do in SwitchYard is make that process a bit more formalized so that you can define you interface up front and consumers of that Camel route (as a service) have a clear contract for how to interact with it.

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.

 

You can define an entire app in SwitchYard today and never tough the SCA part of things, so I'm not sure if this is really a big problem.  I see huge advantages in the conceptual model of SCA, but I don't see a need to expose the actual SCA configuration syntax to users unless they really want to go there.  If you see examples of SCA config muddying the waters, then please let us know.

2) Do Switchyard transforms work within camel routes?  The fact that the camel route is defined as a service make me unsure.

 

They are not called within Camel, but if a Camel route invokes a SwitchYard service, then that invocation will be eligible for transformation.

 

Would it be beneficial to have a mechanism whereby the user can identify certain SY transformation be registered with Camel?