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, 03 Jan 2017 13:37:58 GMT

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

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

Can you only configure this now using <bean> style?

That is not desireable. Using <bean> is hard and complex and people have to remember
class names and much more. Its okay you can do it as an alternative way.

But the point is that you configure all your Camel stuff inside <camelContext> like
must of the stuff you can do with data formats, endpoints, hystrix etc.

This gives us type safe configuration, tooling support, documentation in the xsd, dsl etc.

> 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