In HPC we use often SLURM as workload manager. I would like to know if camel or jbpm-camel can to communicate to SLURM ?
I found apache spark but nothing about slurm.
I am interested by any documentation on this subjects.
Thanks for your help
This question is more about-- what API/RPC options are available for SLURM? If it is completely proprietary, than there probably isn't an available Camel component, but one could be put together using one of the low-level socket camel components, such as mina / netty / etc.
Related
I would like to know if it is possible to use reactive streams in Apache Camel. I know reactive-streams is a component from Apache but I couldn't get it to work the way they explain in the documentation. I would like to know if there is any possible solutions available in github that could help me understand apache camel along with reactive-streams except the one's from apache.
I could possibly use Producer Template with reactor-core but the route logic that sits in RouteBuilder configure method would still be blocking I/O. Any helps would be appreciated?
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.
In Fink source, there are flink-stream-java and flink-stream-scala modules. Why do we need two modules for flink streaming?
https://github.com/apache/flink/tree/master/flink-streaming-java
https://github.com/apache/flink/tree/master/flink-streaming-scala
Both flink-stream-java and flink-stream-scala provide a similar API to manage Flink Streams ; you only have to use one of them, depending on your language.
Please note that whatever your choice, some dependencies like flink-runtime and flink-clients depend on a version of scala (2.11 or 2.12), because Flink is based on a framework written in scala, Akka.
There is an ongoing effort to remove scala dependency from a higher level API, flink-table (FLINK-11063).
flink-stream-java is the implement of java api for stream. flink-stream-scala is the implement of scala api for stream. So you can find DataStream.java in flink-stream-java, and DataStream.scala in flink-stream-scala.
These two modules will accomplish the same function, but different developers receive different languages, and personal task scala is more suitable for operator description in languages such as big data, flink spark, etc.
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.
I am new to serviceMix, I downloaded serviceMix 4.5.1 a couple of days ago.
When I tried to install ode in serviceMix using the command
features:install ode
It tells me this:
Error executing command: No feature named 'ode' with version '0.0.0' available
I googled/baidued mass of webs, I got a bad news that:
"Fuse ESB 4.4 does not support Apache ODE. The latest version of ODE is not compatible with Fuse ESB."
which comes from
http://fusesource.com/forums/thread.jspa?messageID=11209
Fuse ESB - ODE installation
So if serviceMix 4.4 does not support ODE any longer, what is the alternative way to do the web service orchestration in serviceMix? I have tried use camel to do this work,but that's not easy.
How about "bpel-g"?(http://code.google.com/p/bpel-g/) is it a good choice? or any other choice?
Any help will be really appreciated.
I like Activiti for processes and orchestration.
Never run it inside Karaf/SMX/Fuse ESB but it should be possible, if not using this instruction.
It also has a nice web explorer for human tasks etc. if you need it and BPMN modeller for rapid desing and visualization
I would recommend to try bpel-g. A colleague and me have been doing some BPEL conformance benchmarking lately (fyi: the benchmarking tool is available at github) and bpel-g turned out have the highest degree of support for the BPEL spec., along with the older ActiveBPEL engine from which bpel-g is a fork. ODE ranked third place.
Another nice feature of bpel-g is that it is indeed actively maintained. I don't know how well it integrates into the infrastructure of Fuse ESB, but since it's deployable as a war, this shouldn't be much of a problem.
UPDATE: Just had a look up: bpel-g seems to integrate with camel and provides a custom handler to invoke camel components. So, basically, the solution outlined in Petters answer also applies to bpel-g and, in contrast to Activiti, it has a message correlation framework. Finally, the barrier to using it should be smaller, as you already know BPEL. As a consequence, bpel-g might be a more suitable solution here.