Hi Eric,
Here is a diagram that I have created based on your response. I think
that it should confirm what we have discussed - correct ?
Regards,
Charles
On 19/01/16 15:47, Eric Wittmann wrote:
> Hi Charles. I'm not 100% certain I understand all aspects of your
> question - perhaps a diagram would help me, in case my answer doesn't
> make sense (and if you have the time). :)
>
> You are right that there is no 1..N mapping of an apiman service/api
> to a back-end endpoint URL. That is a feature we are contemplating
> for the future but it's certainly not available yet.
>
> Here are some thoughts that might be useful/relevant to this use case.
> First is that you could of course implement a custom policy that
> changed the back-end endpoint URL based on whatever criteria you see
> fit. The custom policy would simply have to change the value of the
> ApiRequest->Api:endpoint field. Doing that should be considered
> unsafe and a temporary workaround, as the Api object is globally
> scoped, and really should be either cloned (if we want to suppor this
> use-case) or immutable (if we don't).
>
> Another thing to note is that as of 1.2.0.Final we support system
> property and environment variable replacements in the API endpoint,
> endpoint properties, and all policy configurations. This means that
> you could install *identical* gateways on all the per fuse server,
> configured using the same shared registry. Then, when you configure
> the Service/API endpoint, you could set the value to something like:
>
> ${external_url}
>
> Then you could set a system property, which could be different for
> each gateway node, like so:
>
> (on gateway server 1)
> -Dexternal_url=http://fuse_server_1:port/
>
> (on gateway server 2)
> -Dexternal_url=http://fuse_server_2:port/
>
> That way your configuration is shared but certain aspects/properties
> of the configuration are *externalized*.
>
> This feature was originally meant to support more easily migrating
> data between dev/test/prod environments, but it would work fine for
> this as well.
>
> Did any of that help?
>
> -Eric
>
>
> On 1/19/2016 5:30 AM, Charles Moulliard wrote:
>> Hi,
>>
>> If I use a loadbalancer (= F5) exposing a physical IP address (= routed
>> on internet) and calling one of our endpoints (REST, ...) running into
>> different integration servers (Fuse + Camel), can we design such
>> topology ?
>>
>> We setup an Apiman Manager (Front + ElasticSearch Database) to define
>> the plans, services, roles, policies of all the endpoints which are
>> running into different Fuse Servers. As the mapping between the incoming
>> request and the endpoint is managed by the Apiman Gateway, I'm thinking
>> to install one Apiman Gateway / Fuse Server.
>> Is it doable ?
>>
>> Client --> 192.168.1.1 (IP Address of the Server replying to a REST
>> Service) "Loadbalancer F5" --> NAT --> address of the gateway (=
>> 10.0.2.1) managing the mapping between the request and the physical
>> endpoint --> Camel REST Endpoint (10.0.1.1). The Apiman Manager could
>> run internally on this addess (10.0.2.100).
>>
>> To support high availability or workload distribution, it will be
>> required that at least each Camel REST / Web Service runs into multiple
>> instances of Fuse Servers. That means that their IP address will be
>> different (A REST service will be deployed on 10.0.1.1, 10.0.1.2,
>> 10.0.1.3, ...).
>>
>> Question : As the GUI interface of the Apiman Manager to encode the
>> address of the endpoint to map proposes one field (and no more if we
>> would like to distribute the requests to different servers), is there a
>> possibility to define a 1 to many relation into ApiMan Server (maybe if
>> we develop such a feature) or do I have also to install an Apiman
>> Manager / Gateway per Fuse Server and to encode the same info (plans,
>> services, ...) excepted the IP address of the server which is
>> different ?
>>
>> Regards,
>>
>> Charles
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/apiman-user
>>