Christian, I've also seen a lot of people using Processors/Exchanges which unnecessarily couples their cod to the Camel framework. Unfortunately the Camel in Action book doesn't get around to advising against that practice until your well over 100 pages into the books. And when it does it is in a bulleted list at the end of a chapter. When I'm at client sites it's one of the first things I teach them when mentoring developers. Use POJOs and unit tests just like any other code. Unfortunately neither the Camel website nor the Camel in Action book stress this and too many code examples use Processor/Exchanges unnecessarily. Honestly, in the past six years, I don't recall the last time I used Camel Processor/Exchange directly.
But services aren't more loosely coupled than messaging. If I have bundle A with all its classes unexported in ".internal" package and bundle B in the same situation but they communicate via Camel routes, that's decoupled at compile time and at runtime. Injecting a service interface whether it is through a proxy or not couples the two bundles at compile time and temporally couples them at runtime. If one puts the service interface into a separate bundle one now has a different dependency. A good example of where I think services are exceptionally well suited is your PAX JDBC data source. Being able to switch the configuration and have the data source become available as a service that is disambiguated by JNDI name is fantastic. Currently I'm using that mechanism to inject the DataSource into a bundle that uses Camel SQL component. There are multiple routes in that bundle and each executes a different .sql file and returns the results. The DataSource injection makes a lot of sense as I can instantiate the Camel SQL and use it. But I can think of a reason to implement a service interface to expose those endpoints to the world. That's an interesting observation about only using standard Java types on the service interfaces. I hadn't really thought about that before but will keep it in mind. Thanks. Brad On Friday, August 11, 2017 at 6:40:36 AM UTC-5, Christian Schneider wrote: > > I agree. Not using services in OSGi is a bad idea. Services allow you to > keep your bundles loosely coupled. > You should also try to only use standard java types in your service > interfaces. > > I have seen some cases where people share camel routes between bundles or > use camel classes in service interfaces. In the start this seems fun but as > your system grows you realize that the coupling badly hurts your ability to > evolve parts of your system. > > Also when using services try to avoid retrieving a service and blocking > until it is there. Instead let DS or another DI framework inject the > service. Especially using DS this will make your system highly reactive to > changes and even work when things are replaced at runtime like in > development. It also copes well with refreshes like they happen a lot in > apache karaf when you install features. > > Christian > > 2017-08-11 9:51 GMT+02:00 'Christoph Läubrich' via OPS4J < > [email protected] <javascript:>>: > >> Well in fact here is no framework that solves all your problems... I'm >> using OSGi and DS for year now and it works without a problem, even though >> there where sometimes bugs in the code or flaws in my concepts or >> architectural decsions I had to solve. But I never exspected that DS, OSGi >> or anything else "solves" this for me in a magical way. >> >> If you want to use OSGi DS is IMO the best choice (as mentioned before) >> because it provides what we have with bundles and import/exports to the >> service level, but must be used with OSGi in mind. The problem is that ppl >> exspect the can just throw things togeter and it would then work in some >> magical way. >> >> >> You can add Blueprint, CDI, Camel and whatever to the mix try to keep >> away OSGi but will be hurt by "flaky" things then. Thats not the fault of >> the framework/lib but a restriction of the programming model. I can't find >> "use of services ends up being complex" but the other way round: Using >> services with DS is incredible easy and powerfull. So if you have a >> problem, provide an example and I'm sure you will get help to solve the >> problem. >> >> Also DS can of course be used to wire up "things" inside your bundle, >> what should keep you away of doing so? >> >> Am 10.08.2017 22:37, schrieb [email protected] <javascript:>: >> >>> I did use it not too long ago but had to get back to a paying gig. But >>> the technology is certainly what we need, I think. >>> >>> SCR is fine until you then realize that you have wire things up in your >>> bundle and don't have too many good choices about the matter. Blueprint is >>> a little long tooth and clunky to work with. From what I've heard from >>> Christian and others it sounds as though the proxies have naughty habits. I >>> can say that with time I've drifted away from using OSGi services when I >>> have a reasonable choice between using a service and something like a Camel >>> route. A lot of that has to do with the path of least resistance. I'm >>> putting in a system right now that has a data source bootstrapped via PAX >>> JDBC which is then consumed by a "connector" bundle (essentially a DTO). >>> Initially I'd exported that connector as a service for other bundles to >>> pick up and make service calls. But the services seemed to have flaky >>> problems when I uninstalled/installed. Since I had other issues to solve I >>> just fell back to using Camel routes for data access from other bundles. >>> >>> That doesn't seem to be a unique situation for me with Blueprint. Maybe >>> it isn't Blueprint. But the use of services ends up being complex and >>> that's a shame. If there's a technology like CDI that lets me easily export >>> and reference service that will be spectacular. I was stunned about how >>> easy is to test with the CDI anotations. >>> >>> Of course, for bread and butter I'm still consulting on Fuse and that's >>> not exactly cutting edge.... >>> >>> >> -- >> -- >> ------------------ >> OPS4J - http://www.ops4j.org - [email protected] <javascript:> >> >> --- You received this message because you are subscribed to the Google >> Groups "OPS4J" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> > > Open Source Architect > http://www.talend.com > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com> > -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
