We have a requirement to enable Role Base Access Control on Camel routes. Say group 'A' manages a group of Camel routes so only group 'A' can stop/start this group of Camel routes. Monitoring capability can be viewed by support and development groups.
We are going towards Karaf and HawtIO for the container and the UI with Camel. Is the above requirement doable within HawtIO/Karaf/Camel stack? I have seen that we can enable access to HawtIO through JAAS but it seems like once you are in, you are in which is not what we are looking for.
Any help is appreciated.
You cannot do this per Camel route that is too fine grained. The Karaf RBAC allows to configure roles per JMX mbean operation and attributes.
The call to stop a route is using an operation on the CamelContextMBean and calling stopRoute with the name of the route. So you cannot use RBAC as all users would use the same operation.
You would need to add some custom code into hawtio to do some kind of validation yourself.
Besides start/stop of routes based on groups. What other access control on Camel etc are you looking for? We may gather a number of requirements and see if there is something we could add to hawtio / Camel / Karaf etc.
Related
Background: We have written a Spring Boot Apache Camel based ingestion service which runs Camel routes that ingest data from shared directory (Excel files) and Jira (API calls). Jira based routes are fired using Scheduler at pre-defined frequency. User configures multiple integrations in the system and each integration maps to one Camel route. In production, there shall be 10 instances of the ingestion service running.
Problem Statement: For each integration using Jira, only one ingestion instance should fire a route, process it and rest should not if there is already a running instance for that specific route.
Question: How to make sure only one ingestion instance processes a route and rest ignore it (i.e. may start but stop after doing nothing)?
Analysis: It seems Camel Cluster component can be used but not sure if it can be used in conjunction with scheduler component. In addition, since cluster component can rely on standalone components such as cache, file etc., preferred solution would be to use something that does not require any new components in the architecture. Also it may be possible to use a custom solution but preference is to use an out-of-box solution.
Could anybody explain how Apache Camel is able to behave as a routing and mediation engine on a JAXRS API?
As far I've being reading about I've not been able to figure out what's it for?
You can consider Apache Camel as a great integration framework. It doesn't provide functionality itself, but it makes easy to glue multiple services and protocols together.
Apache Camel can expose a REST endpoint using the CXFRS component. This means it listens for a REST call on certain endpoint (URL). On invocation it doesn't invoke the implementing bean (service) itself, but executes a defined mediation route (invoke a route with its Exchange object).
It is very useful when you need to integrate multiple services or translate the call to other protocols. You can implement a REST service by a bean itself and it's ok until the bean provides some functionality or data itself. For integration you often need more flexibility to integrate multiple sources and protocols. Then Apache Camel can be much more practical tool.
I saw that HawtIO has a Dashboard that shows the flow of the route into each processor in it and the count for each call made.I checked into the apache Camel,I believe you are reading the JVM for getting the metrics of the Routes and the processors in it but what I don't understand is how are you able to construct this block diagram and the exact flow into each processor..
Can someone help me out with this.I am trying to build a similar UI such as hawtIO for specifically on Apache Camel and I want to know how it can be done?
Hawtio is getting its application insights with Jolokia. Jolokia is providing a HTTP bridge to JMX. So, in other words, all the informations you need are exposed by Camel MBeans via JMX.
So, you have two options to get hold of Camel's JMX info:
base your own UI on Jolokia as well.
go old school and use a JSR-160 connector.
I use dynamic routing my integration project, which may be multiple camel contexts.
I can see if there is an endpoint in one camel context:
getContext.hasEndpoint("nmr:targetEndpoint")!=null
But it does not work if the endpoint is in another camel context...
I am still struggling with undertsanding some of Camel's main features and limitations.
My objective is to implement a demo application that can migrate camel endpoints. To achieve this everyone suggested that I should use the camel load-balancer pattern with the failover construct.
To achieve this objective people have suggested Fuse and ActiveMQ. Some have even suggested JBoss, but I am lost.
I understand that Camel needs the an implementation of a JMS server. To achieve this I can use ActiveMQ - a free implementation of a JMS server.
However camel also provies the jms-component. What is this? Is this a client implementation of JMS? If so, should I not be using an ActiveMQ client for JMS? Could someone provide a working example?
With ActiveMQ and JMS understood I can then try to find out why people suggest Fuse. I want my implementation to be as simple as possible. Why do I need Fuse? The Camel+ActiveMQ combination has the load balancer pattern with the failover mechanism right?
I am lost in this sea of new technologies, if someone could give a direction I would be thankful.
Camel provides two components. The first is the jms component, which is a generic API for working against JMS servers. The other is the activemq component, which uses the activemq API for working with activemq message brokers. The activemq component is the default component within things like servicemix/fuse, using an internal broker (not a networked/external broker).
If you are connecting to activemq, you can use either the activemq component or the jms component. The jms component will not start up a broker automatically, you would need to do this yourself.
Fusesource == JBoss Fuse == Apache ServiceMix + some addons. For argument sake, i'm going to refer to all three of these as ServiceMix.
ServiceMix is an enterprise service bus, you can lookup the term on wikipedia if you're not familiar with the concept. It uses Apache Camel to define routes between your components, implementing a number of integration patterns as you so need. ServiceMix deploys by default with Apache CXF, for JAX-RS and JAX-WS services and Apache ActiveMQ, a JMS message broker. Using Camel, you can tell service mix that when a REST API is called, do a series of steps, each step decoupled from the one before it.
JBoss Fuse (the enterprisey, costs money edition) comes with some additional components around fail over. Some of these are present in servicemix (namely, you can run servicemix in a hot stand by mode, waiting for the primary to go down). The Camel load balancer pattern doesn't really mean anything around replication, except that a message coming from one endpoint can be delivered to any of a set of a N endpoints. http://camel.apache.org/load-balancer.html
On the flipside, take a look at ServiceMix's failover http://servicemix.apache.org/docs/4.4.x/users-guide/failover.html
I think based on your question you're referring to system failure failover (needing to work against a new instance), and not a Camel Loadbalancer component (which is likely where the confusion is coming from, on the community side and your side).
start by reading these...Camel In Action, ActiveMQ In Action