I am exploring the possibility of using the community version of FUSE ESB in a production system for a period of one year. Is it possible? Can you please provide some advice here?
Just like RHEL, can I continue to use RedHat Jboss FUSE in production environment free of cost, without availing the support? If I understand correctly, the subscription is for support.
Have your legal team review the agreement. My understanding matches yours. There are no technical limiting factors (no registration keys, etc), and Fuse is free to use the software for development purposes, but production usage requires a subscription.
Your understanding is correct. The entitlement is for support, not product usage.
Related
Question is above. I read that you have to pay for this service and now I want to cancel it. Is that possible? Or am I wrong and it is actually for free? I also tried deleting it but I keep getting the message that I can't install multiple versions.
If you are not a MongoDB customer, your use of MongoDB Enterprise Server is governed by the customer agreement that is presented during the download process (e.g. here). This agreement says:
(b) Free Evaluation and Development. MongoDB grants you a royalty-free, nontransferable and nonexclusive license to use and reproduce the Software in your internal environment for evaluation and development purposes. You will not use the Software for any other purpose, including testing, quality assurance or production purposes without purchasing an Enterprise Advanced Subscription. We provide the free evaluation and development license of our Software on an “AS-IS” basis without any warranty.
You may use the product indefinitely as long as you are using it for "evaluation and development purposes".
You can also uninstall the enterprise server at any time and install the community one.
does anyone know how licensing works for JBoss Fuse in a DR environment - say for example we need an active AMQ container running in DR with replicated db, would this count towards the core licensing?
If so is there any way to have anything other than cold DR without a license impact.
Technically, JBoss Fuse is not licensed. One would purchase an entitlement/subscription from Red Hat. An entitlement allows access to both the software and technical support. There is a 'self-supported' entitlement that provides access to the documentation and the knowledge base and software, but does not include the ability to open a support case.
There is no restrictions on the number of deployments with an entitlement.
Doug
I'm evaluating PaaS alternatives. One of my requirements is to support JBoss. Any suggestions, in addition to OpenShift, preferably including a simple but technically competent installation description.
Thanks in advance!
Rodrigo
If you are looking to set up a PaaS which supports JBoss, Cloudify, the open-source PaaS stack, has a JBoss Recipe: https://github.com/CloudifySource/cloudify-recipes/tree/master/services/jboss
Disclaimer: I am one of the developers of Cloudify.
OpenShift (from Red Hat - the JBoss people) supports EAP6.1, AS7, about to release wildfly, and all your DB right there on the platform.
Caveat - I work as an evangelist for OpenShift
Is there a difference between Drools and Jrules? Is Jboss rules the same thing as Jrules? What type of environments typically use Drools?
Similarities:
At the end of the day these two applications are BRMS so yes, they are similar
Both offers you the ability to:
- store rules in a repository
- write rules in a web environment
- execute the rules on a server
JRules is from far the best approach for business users (non technical).
JBoss rules is from far the best approach if you look for a non stupidly expensive solution
Both can do CEP as well. (Complex Event Processing)
Differences:
JRules is more mature than Drools but Drools is a great tool to work with
Drools uses JSON to write technical rules JRules uses IRL (Ilog Rule Language). Don't worry you can add "verbalisation" with Drools but it is less powerful than with JRules.
The main differences are from a business (non technical) point of view.
If you want to be able to write a rule in a proper human language like :
if the age of the applicant is less then 18 then reject the application;
you can do it with both.
Now if you want the business to write rules in Hindi, review them in French, validate them in German and do some report in English then JRules is the BRMS you need.
You can write rules directly in Excel or Word with JRules.
Because Drools is from the free world you may face some few bugs but as it is free, you have access to all the source code compare to JRules where part of the API is hidden
What environment:
For Drools I would say JBoss :)
JRules = JBoss, WebSphere, Weblogic, Tomcat, ... and more
For this one: RTFM really. Depends on your needs.
Google may give you some benchmark on the various BRMS.
To sum up:
If you have money (loaded) then JRules
If you are poor or geeky then Drools - you will have fun, really :)
Note: I talk about "Drools" not "JBoss rules" supported by Red Hat.
Difference between them is the Red Hat version is not the latest Drools one and do not have exactly the same functionalities as Drools.Simply because Red Hat support their version so they evoluate less quickly than Drools. Basically they choose a version at one time and decide to use it while drools still change... You got my point, hopefully.
Hope it helps
No, Drools is the open source rules engine. It includes several sub projects, like Drools Expert, Drools Fusion, Drools Guvnor, etc.
Red Hat packages and supports Drools as the JBoss Enterprise BRMS product.
JRules is the rules engine from ILOG that was acquired by IBM.
From Red Hat's site:
For example, did you know that between the JBoss Drools community
project v5.1 and Red Hat's JBoss Enterprise BRMS v5.1, there were 150+
bug fixes, 5 security fixes, and several performance enhancements? ...
Red Hat's JBoss Enterprise BRMS product is based on the innovative
work done by members of the JBoss Drools community project. However,
it is not a one-to-one relationship and only JBoss Enterprise BRMS
offers assurance from Red Hat through an enterprise subscription that
includes patches and updates, SLA-based support, and multi-year
maintenance policies. With Red Hat's JBoss Enterprise BRMS, you can
manage the technical and political concerns that get in the way of
deployment.
Our support is first class. The Red Hat Customer Portal is award-
winning and Red Hat consistently outpaces proprietary competitors in
support rankings.
But JBoss Enterprise BRMS is more than product stability. Our
professional services team has a wealth of experience that will help
even the most experienced JBoss Drools developers to harness the full
power of the rules platform. And powerful it is!
JBoss Enterprise BRMS: where the power of JBoss Drools meets the
assurance of Red Hat.
I am looking for a kind of java ee application server. My company is using Websphere application server and I am reviewing jboss. I am not familiar with WAS, would anybody like to tell me which outstanding features provided by IBM WAS? And what the common features between WAS and JBOSS.
I write down my understanding firstly.
IBM WAS Outstanding(Specified) features:
1. LTAP
2. Monitor Tool
3. IDE(RAD) --- not sure is it free?
4. Integration with IBM portal(since we are using this product as well)
5. Integration with IBM MQ(above reason)
6. Webservice extension support(WS_*)
7. .....cool websphere library??? no idea, who would give me a sample?
Common features in WAS and JBOSS
1. Vendor service support
2. Java EE and EJB 3.0
3. Clustering
4. Any reasonable features for web2.0 application?
I don' think you should make comparison this way. Get the IBM team to provide you their list and speak to RedHat and get their list and then make the comparison.
RAD is not free by any means.
WAS is a good stack as it has a good track record in high volume sites and is the foundation of a number of IBM products (e.g Process Server, Portal Server etc).
The flipside of WAS is the learning curve is steep and the machine requirements are steep too.
Historically WAS was lagging in the support for latest versions of Java EE. Things are improving these days though
HTH
Manglu