[jira] [Comment Edited] (CAMEL-10638) Refactor ServiceCall EIP

["Luca Burgazzoli (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-10638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15812282#comment-15812282 ] 

Luca Burgazzoli edited comment on CAMEL-10638 at 1/9/17 5:14 PM:
-----------------------------------------------------------------

[~davsclaus]

You can now configure the eip using type safe xml dsl, like: 

{code:xml}
   <serviceCallConfiguration id="service-call">
        <etcdServiceDiscovery servicePath="/etcd-services-0/"/>
        <ribbonLoadBalancer/>
    </serviceCallConfiguration>

    <route>
        <from uri="direct:sc1"/>
        <serviceCall name="http-service" configurationRef="service-call"/>
    </route>
   
    <route>
        <from uri="direct:sc2"/>
        <serviceCall name="http-service">
            <staticServiceDiscovery>
                <servers>service1@localhost:9101,service1@localhost:9102,</servers>
                <servers>service2@localhost:9201</servers>
            </staticServiceDiscovery>
            <ribbonLoadBalancer/>
        <serviceCall>
    </route>
{code}

So now you can safely mix different technologies.
As I've changed lot of things, a quick review would be really appreciated.




was (Author: lb):
[~davsclaus]

You can now configure the eip using type safe xml dsl, like: 

{code:xml}
   <serviceCallConfiguration id="service-call">
        <etcdServiceDiscovery servicePath="/etcd-services-0/"/>
        <ribbonLoadBalancer/>
    </serviceCallConfiguration>

    <route>
        <from uri="direct:sc2"/>
        <serviceCall name="http-service" configurationRef="service-call"/>
    </route>
   
    <route>
        <from uri="direct:sc2"/>
        <serviceCall name="http-service">
            <staticServiceDiscovery>
                <servers>service1@localhost:9101,service1@localhost:9102,</servers>
                <servers>service2@localhost:9201</servers>
            </staticServiceDiscovery>
            <ribbonLoadBalancer/>
        <serviceCall>
    </route>
{code}

So now you can safely mix different technologies.
As I've changed lot of things, a quick review would be really appreciated.



> Refactor ServiceCall EIP
> ------------------------
>
>                 Key: CAMEL-10638
>                 URL: https://issues.apache.org/jira/browse/CAMEL-10638
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-consul, camel-core, camel-etcd, camel-kubernetes, camel-ribbon, camel-spring-cloud
>            Reporter: Luca Burgazzoli
>            Assignee: Luca Burgazzoli
>             Fix For: 2.19.0
>
>
> As today the ServiceCall is implemented loading a ProcessorFactory using a ServiceLoader like system but this may cause issues as if you have multiple components providing an implementation of the ServiceCall SPI so i.e. if you have both consul and etcd components in the classpath, the following set-up will be initialized with the first ServiceCall SPI found in the classpath regardless of the consulConfiguration/etcdConfiguration:
> {code:java}
> from("timer:consul?period=1s")
>     .serviceCall()
>         .name("consul")
>         .consulConfiguration()
>         ...
>     .end();
> from("timer:etcd?period=1s")
>     .serviceCall()
>         .name("etcd")
>         .etcdConfiguration()
>         ...
>     .end();
> {code}
> It may be better to have a different way to set-up the ServiceCall so that each element (server discovery, load balancer, server chooser) is provided instead of created by the ServiceCall ProcessorFactory.
> A possible - high level - definition of the classes may look like:
> {code:java}
> interface ServiceCallLoadBalancer extends Processor {
> }
> interface ServiceCallServer {
>     String getServiceId();
>     String getHost();
>     int getPort();
>     Map<String, String> getMetadata();    
> }
> interface ServiceCallServerDiscovery {
>     List<ServiceCallServer> getInitialListOfServers(String serviceId);
>     List<ServiceCallServer> getUpdatedListOfServers(String serviceId); 
> }
> interface ServiceCallServerDiscoveryAware {
>     void setServerDiscovery(ServiceCallServerDiscovery serverDiscovery);
> }
> interface ServiceCallServerChooser {
>     ServiceCallServer choose(List<ServiceCallServer> serverList)
> }
> interface ServiceCallServerChooserAware {
>     void setServerChooser(ServiceCallServerChooser serverDiscovery);
> }
> class ServiceCallConfiguration {
>     public void setServiceId(String serviceid);
>     public void setComponent(String component);
>     public void setUri(String uri);
>     public void setExpression(Expression expression);
>     public void setLoadBalancer(String loadBalancerRef);
>     public void setLoadBalancer(ServiceCallLoadBalancer<ServiceCallServer> loadBalancer);
>     public void setServerDiscovery(String serverDiscoveryRef);
>     public void setServerDiscovery(ServiceCallServerDiscovery<ServiceCallServer> serverDiscovery);
>     public void setServerChooser(String serverChooserRef);
>     public void setServerChooser(ServiceCallServerChooser<ServiceCallServer> serverChooser);
> }
> class ServiceCallDefinition extends ServiceCallConfiguration {
>     public void setConfiguration(ServiceCallConfiguration configuration);
>     public void setConfiguration(String configurationRef);
> }
> class DefaultServiceCallLoadBalancer implements CamelContextAware, ServiceCallServerDiscoveryAware, ServiceCallServerChooserAware, ServiceCallLoadBalancer {
>     ...
> }
> {code}
> The configuration part will be similar to the one we have today except the etcdConfiguration/consulConfiguration/etc will be removed in favor of a generic one, like:
> {code:java}
> ServiceCallServerDiscovery sd = new EtcdServiceCallServerDiscovery(conf);
> from("timer:consul?period=1s")
>     .serviceCall()
>         .name("consul")
>         .loadBalancer("my-load-balancer")
>         .serverDiscovery(sd)
>         .serverChooser(servers -> servers.get(0))
>         .end();
> {code}
> There will be a default implementation of the load balancer so defining it may not be needed but environment like spring-cloud could provide a different implementation.
> [~davsclaus] what do you think ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)