Is anyone using Karaf instead of Servicemix? If so, how did you come to this decision? I'm aware that Servicemix adds a layer of functionality around Karaf, just curious if Karaf is being used on its own and why...
We're using Karaf for a number of our applications. We were already using Camel (JMS and Esper) for integration between several different platforms (a JBoss 4.2 instance, a Tomcat and several Felix instances) and as this was working well there was little justification in migrating this too (which would have been cause to consider ServiceMix).
The only reason we have some Felix nodes, is that they're limited in use (on client desktops), rarely need/get updated and I wanted the smallest footprint for these nodes. For anything OSGi on the serverside we're using Karaf.
Karaf provides all of the features you'd expect and need for a production environment (see the apache-karaf tag's info). We do our development and testing against standard minimal framework (using pax-exam) but deploy to Karaf.
If you don't need an ESB, JCA, BPEL, etc but want a solid, tunable OSGi container, then Karaf on it's own is more than adequate. (And if you found yourself needing a limited subset of ServiceMix's functionality you can always install these in a Karaf instance).
You can also customise the Karaf distribution as part of a maven build - personally I like have the container as part of the application's build, as I can checkout, build and run the entire setup from the command line in minimal time.
Recently there's a clustering subproject of Karaf called Cellar using HazelCast, I not sure if this applies to ServiceMix too.
Karaf's life started as the ServiceMix core. Currently, ServiceMix is really a set of bundles that are deployed into a Karaf container. ServiceMix has a number of very handy bundles which do a lot of cool stuff that karaf doesn't. That said, the two primary reason for using ServiceMix is if you want:
1) an ESB,
2) NMR (a feature that allows you to community between bundles AND instances of Karaf).
This all said, the ServiceMix group is currently planning version 5, which will remove the ESB and NMR features and will be focused on being a management container for Camel. In ESB's a great deal of effort when into creating components that could be described using BPL (Business Process Language). However, the folks that wrote ServiceMix began to focus on the implementation of EIP's (Enterprise Integration Patterns) which largely does the same stuff as BPL, but does it in a more standardized and accepted manner. This work was done under the Camel project.
So, in short. If you are using ServiceMix 4+, you're also using Karaf. If you want a more robust integration environment, the environment of choice today (in the Apache/Felix world at least) is Karaf, Camel, and a few bundles from Servicemix.
Here's a little comparative illustration I made. Going from the simplest case (JVM with OSGi functions provided by Apache Felix at the bottom), to more complete/manageable OSGi functions (Apache Karaf in the middle), to enough functions to implement complete ESB instances (Apache ServiceMix at the top) (note that "an ESB" is not a product but a set of endpoints, routers, databases, ETL functions and whatnot configured together in a particular task-specific way).
Karaf does NOT come with CXF.
Its pure extracted kernel of ServiceMix. However, you can install CXF on Karaf as below.
karaf:root()> feature:repo:add cxf
Once the feature URL is added we can see the "provided" features by using the following command.
karaf:root()> feature:repo:feature:list | grep cxf
To install cxf fire the command below
karaf:root()> feature:install cxf
Related
I am able to get OSGi blueprint to work in Karaf, but I don't understand how to do it in Apache Felix, or my question can be also defined as how can I use OSGi blueprint in plain OSGi?
I made an example here https://github.com/PhilAndrew/sbt-osgi-felix-akka-blueprint-camel using https://github.com/doolse/sbt-osgi-felix in which Akka is working but Blueprint and Camel not yet working.
This question may help Is Apache Aries running in Felix?
It's not starting Blueprint because your bundle's code doesn't actually rely on any of the classes in blueprint, so you either need to add "Require-Bundle" header to your manifest:
requireBundle := Seq("org.apache.aries.blueprint")
or add the bundles that needed to be started to the osgiDependencies of run:
osgiDependencies in run := bundleReqs("org.apache.aries.blueprint.core",
"org.apache.aries.proxy")
Apache Karaf also runs on felix. So for the most part you just need to install the correct bundles and maybe do the necessary system package exports if you hit package use constraint violations.
Check what karaf installs and try to do the same.
Maybe this question seems odd ?
I am working on OSGi-fication of our software based on Agents collecting some informations on servers.
Concerning Bundles update, it's natively supported by OSGi frameworks (OBR, Apache ACE, ...)
But, concerning the OSGI Container itself (Felix, Karaf, ...), is there a mechanism or a framework/tool having capacity to upgrade the container "automatically"?
Any idea? Any feedback?
Not in the OSGi specification. It assumes the framework is available on the classpath and can be launched. Any ability to update the framework implementation would be specific to a framework implementation as a value add.
I have quite a sophisticated OSGi application which uses Declarative Services and was designed to be deployed in Equinox. Now the task is to make this application be deployable in WAS 8.
The first try was quite pragmatic: I have deployed an EAR which has started basically the same Equinox and after some WAS class loading policy tweaks it has worked.
Now I want to go further: get rid of the Equinox runtime and deploy my bundles "natively" in WAS 8. So I have composed an EBA, consisting out of my business bundles, their dependencies and Equinox DS runtime. The EBA is deployed as an asset and integrated into a BLA. The application has even started and runs but the components are not initialized.
The point is that one has to start equinox.ds in front of the own business bundles (UPDATE: not a must, s. discussion below) in order to make DS do its job. But how do I tell the bundles which is to be started first within the deployed EBA? I need some analog of Equinox' config.ini file.
I know I can rewire my components with natively supported Blueprint, but frankly this is the last thing I'd like to do. It should be possible to make Equinox DS work, shouldn't it?
Another question is: how to get the OSGi console for one's own application deployed under WAS 8? I want to control my bundles but seems that there is no way to do it from the Management Console.
UPDATE
Thanks to BJ and Neil (s. discussion below), the question takes down to "How do I start a specific bundle in my own OSGi application deployed in WAS 8.0?"
To answer the OSGi console part of your question, a normal OSGi console won't work because the OSGi applications are managed in nested frameworks. WebSphere provides its own console which can navigate the nested applications: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.websphere.osgi.nd.multiplatform.doc%2Ftopics%2Fta_admin_runtime_console.html
I want to create an OSGi (Equinox) bundle that contains a script engine (JSR-223 compliant) and use it in another bundle via ScriptEngineManager.getEngineFactories().
However the service discovery mechanism of Java Scripting API (jar file service discovery) fails to discover scripting engines in installed bundles.
I already saw few answers on the topic, which suggested using Apache Felix or Apache Sling since they have a solution. However I am wondering if the Equinox implementation has a way to handle the problem?
Well, OSGi 5 will support it, it's called the Service Loader Mediator. That will effectively bridge the OSGi services with the java.util serviceloader.
Apache Aries has an implementation of it called Spi-Fly which should work. I guess it is more targeted at Felix but usually the OSGi implementations are pretty compatible.
To be honest though, I've never gone to the bottom of this one, so I can't speak from personal experience.
Good luck, Frank
I have implemented a solution based on one of the answers from Is OSGi fundamentally incompatible with JSR-223 Scripting Language Discovery? using OSGiScriptEngineManager and friends and that works pretty well.
The big problem then can be to find proper JSR 223 implementations for the scripting languages in question :-)
We're working on an OSGi-based infrastructure for processing stream-based data flows. Specific processing tasks are executed by individual OSGi components. We now need the possibility to distribute those components over different machines, which means, we need some kind of communication mechanism between OSGi components/containers.
During my research I came across different potential solutions: R-OSGi, Apache CXF for Distributed OSGi, Eclipse Communication Framework.
ECF seems particularly interesting as it supports different transports formats and provides support for stuff like service discovery.
My central questions:
Are there any detailed tutorials/walk-throughs for setting up an ECF infrastructure within Felix? (from my research, I found, that Felix support has been added recently)
Are there any solutions besides the three listed above which I might have missed?
Is there a reason for taking Apache CXF instead of ECF?
The first question -- whether there is a detailed walk-through for setting up ECF with Felix -- I don't know the answer to, though one might use a search engine to find out combinations of those terms.
The problem is ECF uses the Equinox infrastructure, and has at times inadvertently relied on packages that are non-public through transitive dependencies (particularly the Runtime API which uses Equinox for non-public debugging). This, in turn, means that ECF relies on a whole host of other components to be available and it's this set which typically isn't well defined on a Felix runtime.
You have missed out Paremus' Service Fabric, which is a commercial OSGi cloud solution. I'm not sure if you were specifically focussing on open-source or not; but if you are including commercial licenses then they have a very robust architecture for remote services.
Finally, the Apache CXF over ECF question -- if you're using Felix, I'd argue that going with Apache CXF is probably easier than going with ECF. This is mainly due to the dependency set and getting it working, combined with the fact that ECF may not be tested on Felix and so may assume particular aspects of the Equinox runtime (which includes, for example, the runtime's parent classloader delegation to pick up things on the boot classpath). This isn't really the fault of ECF per se, but rather an artefact of how the Eclipse ecosystem works.
If you want to communicate with non-OSGi runtimes, there's an advantage in the Apache CXF in that they can generate WDSL for interaction with other languages. I believe that you can do the same thing in ECF with a bit more work. The CXF solution is likely to be more verbose than a corresponding ECF one (WSDL always is) but if you're not using high volumes of requests this isn't likely to make a significant difference.