Exact product and build requirements

Latest response

Hi all, I have a POC for a client which on the surface is relatively simple. I need to model a process in jBPM and show the business rules integratio, with the repository etc. I then need to integrate this process with the JBoss ESB and walk the client through the entire process from modelling staright through to final deployment. Easy enough right? Not really. JBoss Developer Studio 6 does not handle ESB/jBPM development etc and while I am happy to use the web based process developer the problem is which exact stack am I looking for? 

Here's what I think it is:

jBRMS --> for the jBPM and the Guvnor design and build

JBoss SOA Platform 5 --> for the JBoss AS and JBoss ESB components

JBoss DEV Studio 6 (I already have this)

Please would someone provide me the exact links and requirements for me to proceed. When delving into the jBPM 5 Developer guide and the JBoss ESB beginners guide books, both rely on the jboss.org downloads and functionality. What I want is the equivalent stack from RH. The local vendor (Obsidian) that I am collaborating with is in the process of organising the necessary development licenses etc, but needs to know the exact stack for which I need this licensing. 

Thus far I have literally downloaded GB's of software from both RH and jboss.org/sourceforge in order to get my head around what can be done etc. However I am now ready to jump in and begin development and I want it ALL to be done on RH Enterprise Middleware as this is a project requirement.

Is this doable or is the reality that regardless of the project I will have to rely on some bits and pieces from jboss.org that RH do not cater for?





Hi Edward

You're correct. JBoss Developer Studio 6 doesn't contain any plugins for ESB, jBPM development. This is because of the change in the underlying Eclipse version and the Tooling engineers have yet to release the tooling for this.

In the meantime, what I would  suggest you use is JBoss Developer Studio 5, which you can download from [1] and update the SOA Tooling from within JBoss Central. Alternatively, you can download the offline zips from the same location [1].

I hope this helps.



[1] https://access.redhat.com/jbossnetwork/restricted/listSoftware.html?downloadType=distributions&product=jbossdeveloperstudio&version=5.0.0

Thanks Mustafa, so I will download the EAP version with the latest SOA tooling? However this will not allow me to use jBPM 5? Also I have to use a 32 bit jdk on Mac if I would like to use the visual editor tooling? I appreciate the response, but that leaves me with a quandry? How do I in good conscience recommend the jboss Enterprise offering to a client when the latest tooling is sketchy at best? The web process designer is buggy and definitely far from design-->deploy ready.  Essentially from a stack perspective right now if my client wants to use the latest jBPM 5/BRMS stack which RH has touted as READY, they can, BUT: it means that the SOAP5 platform requires hand built ESB components (may as well use VI) which will be manually integrated with any jBPM5 (BPMN2) models. So they essentially have a static jBPM modeller that can be stored in the Guvnor(BRMS) repo as artifacts, but that's about it? 

I would appreciate any input on this matter as from my initial investigation it looks like the jboss.org/eclipse combo is the way to go for the DEV/QA environments? 

Does RH not provide fully prebuilt VM's on RHEL with the preconfigured stacks? After pouring through literally dozens of tutorials and code snippets etc. It looks like it's pretty much "roll your own!!!" If that's the case what's the point of using the JBoss Enterprise offering outside of a PROD environment?

Then the next major frustration for me is everytime you speak to RH there is talk of in the next version.....or great tutorials available for Fuse (not yet PROD ready) or rather use Switchyard etc. etc. (also not PROD ready). An SOA initiative takes at least 18 months to gain traction and from what I can gather the RH product set is set to change/is changing so rapidly at present that getting a solid foundation with which to build on is virtually impossible. 

I would really appreciate any insite into this as at the moment I am realy struggling to make a case for the JBoss Enterprise Middleware offering.





No takers from RH on the why should I recommend the Commercial edition of JBoss?


'Nuff Said!


I would contact your sales representative at Red Hat and talk about options. From your writing I don't recognize the issue. JBDS5 is more than capable of providing tooling to SOA-P 5 (JBossESB) and BRMS 5.3 (jBPM 5).  However, I think you are misunderstanding the purpose of BRMS as we really don't need BRMS if you plan to do all the development of processes and rules from the IDE.

Your concerns about the next versions and road maps of SOA-P is definitely something your sales representative at Red Hat can help you with. You're quite right that Switchyard isn't production ready yet - but it is out there and useful for POCs. If you want to show proof of concepts and if you are looking at a 18 month adoption time, then SOA-P 6 would definitely be more than ready by then. This is one of the advantages of having access to the community versions - they're great for evals and early adapters to get started.

Btw. FUSE is more than production ready. So I would be interested in hearing how you got to that conclussion.  JBoss FUSE doesn't include EAP - however there are lots of examples where you won't need a full application server. Again, I would bring this up with your sales presentative.  We'll be happy to have a talk with you and your team about your product options (I work with Red Hat pre-sales).

Awesome Peter, I really appreciate the response. I would really like to be put in touch with the right people from RH in this regard. Please could you provide me with the necessary contact details so I can get in touch with the right people at RH from a technical pre sales perspective.

You guys have my mail address, so please drop me a mail and we can take it from there.