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

Luca Burgazzoli commented on CAMEL-10638:
-----------------------------------------

Yes for this first part of the refactor. 

I'm thinking how to do add a type safe support inside <camelContext> which 
allow both flexibility (i.e. you can use ribbon with consul) and simplicity 
since some time but I've not yet found a good balance.

What seems a good trade-off is adding specific elements as children of 
serviceCallConfiguration or serviceCall, like:

{code:xml}
<serviceCallConfiguration>

  <ribbonLoadBalancer>
   ..
  </ribbonLoadBalancer>

  <consulServiceDiscovery>
    ..
  </consulServiceDiscovery>  

</<serviceCallConfiguration>
{code}

Would that be reasonable ?



> 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)

Reply via email to