camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CAMEL-10638) Refactor ServiceCall EIP
Date Tue, 10 Jan 2017 09:09:58 GMT

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

Claus Ibsen commented on CAMEL-10638:
-------------------------------------

I wonder if the stuff we have in .remote should be moved to .cloud so its all there?
It looks a bit mixed today.

This is both in impl.remote and model.remote that should be moved to their impl.cloud and
model.cloud.



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

Mime
View raw message