What are different ways to communicate between two OSGi bundles in ServiceMix other than using ActiveMQ.
OSGi services, EventAdmin, REST/SOAP, direct/seda in-memory endpoints in a Camel route.. 100's of other options.
Edit: A good way to think about bundles is that they are just "jars" of Java classes. If you want to do any interprocess communication, you need something to start-up or initialize the classes and then decide what appropriate interprocess communication best suits your use case. OSGi Services are good for things that do not need to go across a wire or between two servers. blueprint.xml provides a Spring-bean-like way of starting classes and other options include the REST/SOAP.. etc.
Depends on how you want sychronous/asychronous, you can use Camel Direct/SEDA/VM component
Related
For integration purposes, we're using Apache Camel, Karaf with OSGi, so we are creating OSGi bundles. However, what Best Practices exist when it comes to structuring the bundles?
The integrations are fairly straightforward, with an incoming document type (via some protocol like HTTPS, SFTP, JMS), transformation to another document type, and again transportation via some protocol. The basic setup is always the same and follows the VETO Pattern: validate, enrich, transform, operate. Each unique combination of the mentioned protocol/docType defines an integration.
We decouple the connectivity (which includes validation) from the other steps via JMS. When we look at the ETO steps we separate those into their own Java classes and their corresponding XSLT. However, what's the added value of the OSGi framework and how should we divide the integrations between the OSGi bundles?
Take into account performing changes, maintenance and deployments? Consider 2 dozen integration points (unique endpoints) with 50 different integrations running in between, in other words 50 unique transformations between two different docTypes. We can put all code & XSLT's of all 50 integrations in 1 bundle (the other bundle handling connectivity), or 50 bundles with 1 integration each. What are best practices, if any, when it comes to deployment strategy? What to take into account?
You can check out examples from Apache Karaf github repository to see how bundles for OSGi applications are structured there. Christian Schneider has also done talk about OSGi best practices and has some examples in his repository as well.
Generally you want to keep your bundles small with least amount of dependencies as possible. Due to this I would recommend having only one integration per bundle. This makes installing integrations and their dependencies easier and offers some flexibility if you ever decide to split integrations between multiple Karaf instances.
For connectivity stuff your best bet is usually to use/create/publish OSGi services. For example with pax-jdbc-config you can use config files to create new DataSource type services which you can then use to connect to different databases from your integration bundles.
Publishing own custom services is pretty easy with declarative services and could easily be used to share connections to internal systems, blob storages, data access objects, etc while maintaining loose coupling by keeping actual implementations hidden with interfaces. For services the recommended approach is to have separate API and implementation bundle so bundles that use the service can just add dependency to the API bundle.
For deployment you can create your own custom Karaf distribution with bundles pre-installed, deploy bundles using Karaf features or use the hot deploy folder. For the two latter ones you might want to configure Karaf to use external folder for bundle configurations and hot deploy as process of updating Karaf is basically replacing it with new installation.
[Edit]
If we have 50+ transformations and put each in its own bundle, then I would have more than 50 bundles to manage. This is just a single instance. Other customers would have their own instances, again running 50+, 100+ bundles
Would say that the key thing here is to try to simplify and identify repetition in bundles. Often these can be converted to something more generic and re-usable.
With OSGi you can use Declarative services and OSGiDefaultCamelContext to instantiate Camel integration instances per configuration file which can be useful if you have multiple integrations that work pretty much the same but only have minor variations. Don't know if camel has support for this with blueprints.
With many bundles efficient use of Karaf features or OSGi features (R8) can be vital for handling the added complexity. Features make it considerably easier to install and update OSGi applications which consist from multiple bundles, configuration files and other features.
Still there's really no rule on how big is too big for single OSGi bundle. Grouping closely related things in to single bundle can make a lot of sense and help avoid splintering things too much.
I am trying to explore is there any tools or any document is available in order to do the Migration from Mule into Apache camel.
please share if anything is available.
Thanks
Arun K
After a quick Internet search I suspect the answer is no. Probably their models are two different. You will need to rewrite from scratch the integrations. Note that Camel.appears to favor a Java DSL approach while Mule uses an XML DSL to configure flows.
However if you have a significant number of integrations in Camel XML DSL it might make sense to create a translator at least to get some base translation that will need to be completed manually.
I am currently learning Camel, and have a specific project in mind that requires a Websphere MQ back-end, but I can't use JMS components, since I need a lot of non-jms headers, like MQIIH.
I found the camel-wmq project.
Is it the recommended solution ? Is it any good ?
You don't need to use jms. WMQ has a client API. Just download the wmq client jars and put them in your project and use them together with your Camel routes. You will probably put the wmq client code in a processor class or something similar. Off course best to test to put a message on a queue manually via RFHUTIL or something similar as a client so you are sure the environment setup is correct.
The suggested way of working with WMQ has always been through the JMS component since it enables you to painlessly switch to other providers if the need arises.
However, if you need to use some WMQ-specific function then my suggestion would be to extend the camel-wmq library - it contains only a subset of features supported by WMQ and does not support MQIIH headers that you need. Adding functionality to a component would probably involve more work than the solution Souciance Eqdam Rashti suggested but it would be a cleaner solution and more in line with Camel's philosophy. Also, you'd be giving back to the community and thus help make Camel a better tool for everyone :)
I would also suggest you go through the IBM MQ discussions on the Camel's official user group mailing list and see if you can salvage anything.
What is the difference between Apache camel-jbpm and jboss jbpm ?
Since Apache camel(2.16.3) is having one component as camel-jbpm.
I am confused which one I should use ? I am integrating with karaf. please suggest.
JBoss BPM (business process - a.k.a human workflow) is a project you can find and read more about here:
http://www.jbpm.org/
Apache Camel is an integration library that allows to integrate with a lot of different system. Doing so by using Camel components. One of these components is camel-jbpm that makes it possible/easier to use JBPM from Camel users.
http://camel.apache.org/jbpm
So if you have an existing BPM system and need to integrate with that from a Camel application or Java application, then using the camel-jpmn can make that (much) easier.
We have a clustered environment where same camel ftp endpoint is installed on multiple fuse instances. I want message(file) to be consumed by only one fuse instance. I am planning to achieve this by implementing IdempotentRepository interface with database persistence. Want to make sure that this approach will work or there is a better way to do it?
If you don't want to depend on a database for doing this you could try with Hazelcast. Hazelcast is a distributed data cache that can be used as a idempotent repository without external dependencies. Also, Apache Camel provides a class for doing this. There is a nice tutorial explaining how to do it: Hazelcast Idempotent Repository Tutorial