[
https://issues.apache.org/jira/browse/CAMEL-10638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luca Burgazzoli resolved CAMEL-10638.
-------------------------------------
Resolution: Fixed
> 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)
