implementation.camel

[beve]

Hi,

I'm working on this jira and posting for some feedback. I've put together a suggestion for this which can be found here.

A Camel route can be used as the implementation for a service. This is done by using the 'implementation.camel' element which can contain a Camel route. SwitchYard takes care of creating a service for the interface which sole purpose is to trigger the Camel route. It does this by creating a 'from' endpoint that triggers the Camel route. This allows SwitchYard clients to use the service interface to invoke the Camel route.

<sd:switchyard 
    xmlns="urn:switchyard-component-camel:config:1.0" 
    xmlns:sca="http://docs.oasis-open.org/ns/opencsa/sca/200912" 
    xmlns:sd="urn:switchyard-config:switchyard:1.0"
    xmlns:bean="urn:switchyard-component-bean:config:1.0">

    <sca:composite>

        <sca:component name="WarehouseComponent" >
            <bean:implementation.bean class="org.switchyard.component.camel.deploy.support.WarehouseServiceImpl"/>
            <sca:service name="WarehouseService" promote="WarehouseService">
                <sca:interface.java interface="org.switchyard.component.camel.deploy.support.WarehouseService"/>
            </sca:service>
        </sca:component>

        <sca:component name="CamelComponent">
            <sca:service name="OrderService" >
                <sca:interface.java interface="org.switchyard.component.camel.deploy.support.OrderService"/>
            </sca:service>

            <sca:reference name="WarehouseService">
                <sca:interface.java interface="org.switchyard.component.camel.deploy.support.WarehouseService"/>
            </sca:reference>

            <implementation.camel>
                <route xmlns="http://camel.apache.org/schema/spring" id="Camel Test Route">
                    <log message="ItemId [${body}]"/>
                    <to uri="switchyard://WarehouseService?operationName=hasItem"/>
                    <log message="Title Name [${body}]"/>
                </route>
            </implementation.camel>
        </sca:component>

    </sca:composite>

</sd:switchyard>

As you can see in the above configuration that the route in 'implementation.camel' does not contain a 'from' route. This is mainly to demonstrate that a 'from' route is created by SwitchYard. It is perfectly legal to have multiple 'from' routes and SwitchYard supports. This allows users to use a route and copy it in to a SwitchYard configuration and have it exposed as a SwitchYard services as well as the possible other 'form' components.

The above would be invokable by using the following code from a SwitchYard test:

String title = newInvoker("OrderService").operation("getTitleForItem").sendInOut("10").getContent(String.class);

Running the above code snippet would generate the following in you console log:

18:05:14,968 INFO  [impl.DefaultCamelContext] Total 0 routes, of which 0 is started.
18:05:14,969 INFO  [impl.DefaultCamelContext] Apache Camel 2.6.0 (CamelContext: camel-1) started in 0.757 seconds
18:05:15,880 INFO  [impl.DefaultCamelContext] Route: Camel Test Route started and consuming from: Endpoint[vm://CamelComponent/OrderService]
18:05:15,880 INFO  [impl.DefaultCamelContext] Apache Camel 2.6.0 (CamelContext: camel-1) is starting
18:05:15,880 INFO  [impl.DefaultCamelContext] Total 2 routes, of which 2 is started.
18:05:15,880 INFO  [impl.DefaultCamelContext] Apache Camel 2.6.0 (CamelContext: camel-1) started in 0.000 seconds
18:05:15,964 INFO  [Camel Test Route] ItemId [10]
18:05:15,966 INFO  [Camel Test Route] Title Name [Fletch]

Notice the Camel Endpoint 'vm://CamelComponent/OrderService', this is the endpoint that SwitchYard generates and currently defaults to 'vm' but we should make this configurable.

Any thoughts on this?

Regards,

/Daniel

[beve]

I've just updated the topic branch with a suggestion for the configuration. This is simply a property that is added to the component:

<sca:component name="CamelComponent">
            <sca:service name="OrderService" >
                <sca:interface.java interface="org.switchyard.component.camel.deploy.support.OrderService"/>
            </sca:service>

            <sca:reference name="WarehouseService">
                <sca:interface.java interface="org.switchyard.component.camel.deploy.support.WarehouseService"/>
            </sca:reference>

            <implementation.camel>
                <route xmlns="http://camel.apache.org/schema/spring" id="CamelTestRoute">
                    <log message="ItemId [${body}]"/>
                    <to uri="switchyard://WarehouseService?operationName=hasItem"/>
                    <log message="Title Name [${body}]"/>
                </route>
            </implementation.camel>
            <sca:property name="schema" value="vm://"/>
</sca:component>

So this way, you can configure the most appropriate Camel Component to use for the endpoint that SwitchYard creates.

[kcbabo]

This looks good to me.  Two quick questions:

1) Can you elaborate on what you mean by "It is perfectly legal to have multiple 'from' routes" ?  Are you referring to the fact that the route can be tied to multiple composite-level service bindings?

2) The property bit is interesting.  What do you think the set of possible "schema" values would look like?  I would have thought that this would also be a switchyard: endpoint behind the scenes that acted as a consumer in the route.

[beve]

1) Can you elaborate on what you mean by "It is perfectly legal to have multiple 'from' routes" ?  Are you referring to the fact that the route can be tied to multiple composite-level service bindings?

What I meant was that you won't get an error if you specify a 'from' endpoint in the Camel route. So you could have a from("file://input") for example and that would still work. We could add a check for this is we wanted to but this might be nice to have the possiblity of multiple 'from' endpoints.

2) The property bit is interesting.  What do you think the set of possible "schema" values would look like?  I would have thought that this would also be a switchyard: endpoint behind the scenes that acted as a consumer in the route.

I was thinking that this could be different schemas like 'vm', 'direct', and perhaps others depending on the requirements of communication. Hmm, that is not how the current implementation works but let me take a look at doing it that way. I might have been a little blind here.

[kcbabo]

What I meant was that you won't get an error if you specify a 'from' endpoint in the Camel route. So you could have a from("file://input") for example and that would still work. We could add a check for this is we wanted to but this might be nice to have the possiblity of multiple 'from' endpoints.

Oh, now you have me up on my soap box. :-)  I'm really hoping that we can avoid supporting the specification of the from endpoint in the camel route.  In my opinion, we maximize flexibility and retain all of the power of Camel if we send to/from SwitchYard endpoints inside the route.  This allows for separation of binding details from the actual routing logic, which seems to me to be a good thing in SwitchYard.

Please correct me if I'm wrong, but I think this is related to an earlier use case you brought up where users might already have a Camel configuration that they want to run inside SwitchYard.  I totally agree that this use case is important.  I guess what I was hoping is that we could provide some tooling assistance to generate a SwitchYard config from the Camel config.  Something along the lines of:

o Each 'to:' that represents a protocol binding (we would need to create a list of these) would result in a composite reference being generated and the Camel configuration mapped to that reference.

o Each route would automatically generate a composite-level service definition.  The binding and interface details would be to be supplied after the fact unless we could extrapolate this from the Camel config.

From a user standpoint, I think the above would produce the same basic user experience : I have a route and I want to run it in SwitchYard.  Of course, this is just an example of what sounds good to me.  You can tell me whether it sounds crazy to you. :-)

[beve]

Oh, now you have me up on my soap box. :-)  I'm really hoping that we can avoid supporting the specification of the from endpoint in the camel route.

Ah, no problems with that. This was more a case of me being a little lazy and not adding an explicit check for any from endpoints specified inside of the Camel route.

Please correct me if I'm wrong, but I think this is related to an earlier use case you brought up where users might already have a Camel configuration that they want to run inside SwitchYard.

The was actually not the case here For a pre-existing Camel configuration I think we would require more then just the route element from a Camel config. We would need to support a full Spring configuration for that to work I think so this was not my intention here.

I guess what I was hoping is that we could provide some tooling assistance to generate a SwitchYard config from the Camel config.

Ah cool, sorry I did not pick up on that previously thought you were saying that SwitchYard was not going to support that case and that users would have to edit their Camel configurations for them to work with SwitchYard. So I like this indeed:)

[beve]

I would have thought that this would also be a switchyard: endpoint behind the scenes that acted as a consumer in the route.

Like Keith pointed out, the from endpoint that we generate should be in the format:

from("switchyard://serviceName")

I've updated the topic branch with this change and also updated and the Readme.md

Sorry about the noise with my previous post regarding the additional schema property...not sure what I was thinking:)

There is also now an explicit check now for any pre-existing from in the route configuration and an RuntimeException is thrown which describes that this is not allowed.