Camel Component
Since we plan on adding a Camel component for the 0.1 release, I figured I would kick off a discussion thread on how that component should take shape. We have had some hallway-type discussions about this in the past and Daniel has done some great prototyping work, so it's time to pull that together and git 'er done.
There are two ways that Camel can be integrated in Switchyard:
1) Use Camel endpoints as gateways within SwitchYard. This would come in the form of a camel binding, where the Camel endpoint configuration appears in the binding declaration.
<sca:service name="camelTest" promote="SimpleCamelService">
<camel:binding.xyz>
...
</camel:binding.xyz>
</sca:service>
In the above example, "xyz" represents a binding type and the configuration would be contained in a child element (or attributes) and defined by a schema. Personally, I prefer this over just pointing to a Camel configuration as it tightens up the configuration in terms of validation and provides more flexibility from a tooling standpoint.
We could always allow for a degenerate case of specifying an opaque <camel:binding> which simply pointed to a camel context with configuration in it or maybe a URI string with the config there. Personally, I don't see this as an acceptable long term solution, but it might be something that we leave as an option for bindings where we don't have an explicit binding configuration defined.
2) Use Camel routes to handle pipeline orchestration. In this case, Camel is used in a similar way to the ESB 4.x action processing pipeline.
<component name="SimpleCamelService">
<service name="SimpleCamelService">
<interface.???>
</service>
<reference name="SomeOtherService">
<interface.???>
</reference>
<implementation.camel>
<route>
<split>
<xpath>/status/person</xpath>
<to uri="switchyard:SomeOtherService"/>
</split>
</route>
</implementation.camel>
</component>
Some notes on the above:
- interface.??? needs to be replaced with the appropriate service interface type. This could be Java, WSDL, or another basic type that we add which allows for a simple specification of the mep and expected message/fault types.
- The route definition is embedded in the camel implementation config. We may need more than route there, but for now I'm just focusing on the routing support.
- We could move to a model where a Java DSL could be specified in the project and picked up by a configuration scanner. This would be super awesome if it dovetailed with our CDI support.
- Notice that we are routing to a SwitchYard service and not a concrete endpoint in the Camel route. IMO, this is the best way to use Camel within SwitchYard because it provides a nice dependency view (note the <reference>) and makes it straightforward to externalize the binding configuration from the routing logic.
I'll pause there and let others shoot holes in the above. :-)
