Indeed I didn't read well your lastname ;-). You are right I actually use OSGi service to expose that service but in my implementation I use camel (with ProducerTemplate and some route if needed). It allows me to easily change the technology stack if needed (for example netty, jetty, restlet, spark-rest and so on).
Thx again for sharing your experiences ! On Fri, Sep 25, 2015 at 3:45 PM Christian Schneider <[email protected]> wrote: > Hi Arnaud, > > I guess your mean Christian Müller who I know worked at Worldline some > time ago. That is not me .. though we both are active in the Camel project > which already led to some confusions :-) > > I think I would skip sharing the common prefix and simply have one config > per service you call like http://example.com/api/customers and > http://example.com/api/contracts <http://example.com/api/contacts>. I > would wrap each such service in king of a proxy as an OSGi service with a > plain java interface. So then each service proxy can have its own config > for the uri. You would then still not share the common prefix but you > achieve a nice separation of business logic and technology. It might be > some additional effort at the start but it makes your project more > manageable when it grows. > > In general I would try to implement business logic completely outside of > camel. It should just offer and consume OSGi services. The main effect of > this is that you have a much clearer picture of what the business > requirements are when looking at the code. Unfortunately camel makes it > very easy to mix technology and business logic but this does not scale well > with project size. > > > Christian > > > On 25.09.2015 15:25, Arnaud Deprez wrote: > > Thanks for your answers guys and glad to have some news of your Christian > (It's been a while since Worldline). > > So for example, what I'd like to share is endpoint url. For the database > it's very easy to expose a datasource as a service. > > So to give you the picture, I'm designing an API gateway in front of > multiple backends (I can't say Micro Services right now because it's not as > micro as it's supposed to be right now). > The goal of this API is to be the gateway for third party application. > My design choices was to split my APIs and my Implementations by business > context. > The thing is that for different context, I've to reach the same backend > right now. > > So let's say this backend as the following context-path url : > http://example.com/api > In one bundle I need to call http://example.com/api/customers and in > another one http://example.com/api/contracts > <http://example.com/api/contacts>. > My first idea was to have a environment PID configuration which contains > "backend.base.url = http://example.com/api"; and in each bundles > "customers.url = ${backend.base.url}/customers" and "contracts.url = > ${backend.base.url}/contracts". > I know that it's possible to merge properties like that but only in the > same configuration PID. > The advantage with this solution is that if they decided to split their > backend into one for customer and one for backend (and if they keep the > same API), I can just update my properties customers.url and contracts.url. > > As it doesn't seem to be possible, I think creating proxies for those > service is the best design choice right now but it's a bit over work when I > can simply the http4 camel component. > > Regards, > > Arnaud > > > -- > Christian Schneiderhttp://www.liquid-reality.de > > Open Source Architecthttp://www.talend.com > >
