Why You Should Avoid TIBCO BusinessWorks 6

I used to be a TIBCO fan. Like, honestly.

I spent my whole professional life working on integration projects and I do have a strong experience in ESB products like TIBCO BusinessWorks, SoftwareAG webMethods, Apache Camel etc…

Before working on TIBCO BusinessWorks 6, my clear ESB preference was BusinessWorks. BusinessWorks 5 I mean.
Indeed, TIBCO BusinessWorks 5 used to be a great integration tool, very much stable, very well designed, easy to use etc. I was clearly in love with this version and I have to thank the TIBCO engineers for this.

But this was before. Before BusinessWorks 6.

Even if I consider that ESB as such will become more and more outdated, I am going to simply express my feeling about the product BusinessWorks 6, not about the theoretical concepts themselves. In the meantime, I am not going to reference any other articles, comments or reviews you can find on the internet. This article is solely based on my own one-year BW6 experience.

The problems

The first concept I loved in BW5 was the fact that each component was autonomous. Instead of deploying your application on a server (just like Integration Server on webMethods), you were simply instantiating your component in an autonomous way. Every dependency was embedded inside of the BW5 component. Pretty familiar with the concepts of microservices and fat JAR right? In fact, TIBCO was pretty ahead on such concepts.

With BW6, the core engine has been redesigned and is now based on OSGI. The main benefit is that you can now deploy several BW components on a single JVM. The system is flexible enough to implement whatever granularity you wish (one single fat JVM, one JVM per component, one JVM per logical group of components etc.). This capability is nice but from my perspective, this was not mandatory. As I said with the rise of microservices, engineers tend to favor more and more autonomy.

I do not know really if it is related to the OSGi integration but throwing away the BW5 engine was a huge mistake. As I said BW5 was really much stable. But now with BW6, I faced so many problems with the runtime engine that I feel anxious each time I need to run an application on my local environment or on a remote domain.
Deploying an application for example is not idempotent. You can do a set of actions (e.g. deploying an application A, deploying an application B, starting an application A and starting an application B) and have different results each time.

As Einstein said: “Insanity is doing the same thing over and over again and expecting different results”. I tell you that you may become insane with BW6.

The other main problem is the new Eclipse-based IDE: BW Studio. It is really unstable I do not see real improvements with all the past versions released by TIBCO.

The workspace management for instance is a nightmare. All of a sudden a workspace can crash for whatever reasons and become unusable. So you will have to create a dozen of workspaces per month and waste your precious time. Another problem is that a set of projects can work in a workspace and not work in another workspace. We suspect Studio to keep a local cache of a project state somehow somewhere. Theoretically, an Eclipse-based IDE was a very nice feature but believe me I do hate this IDE and the number of bugs occurring randomly (a problem occurred: widget is disposed, a problem occurred: NullPointerException, an internal error has occurred: null argument and so on…).

By the way, have you ever seen an IDE proposing a “Repair project” option? This is a new feature of BW6. Because Studio is not stable, believe me, you will have to use this function several times per day and praying each time for a concrete fix. As an example, when your workspace is fine but that after having restarted your computer, the projects are now full of errors. This is the moment when you start praying. And the worst part is that even this function is not idempotent! Repairing a project may not lead to the same results than repairing the project twice. Very frustrating…

In the meantime, renaming a BW asset can also lead to some random bugs. Do not expect to feel confident if you have to simply rename a service, an operation or whatever. In some cases the action will work, in other cases, this will lead to corrupting your project.

The shared modules are another part of the whole BW6 problem. These are more or less based on the same principles than BW5 DTL.
The first problems with shared modules are that if your schemas are a bit too complex (I will come back to what complex means hereunder), you will not be able to achieve the same level of reusability than in BW5. In my company, we decided to not embed our schemas into shared modules but to simply copy paste them into each BW application because of known limitations. The second problem is at design time. The shared modules are not compiled and so not managed as binaries by BW Studio. There are managed like any other projects with a source you can modify on the fly. This was tackled by a recent BW release but still with many limitations and you can still modify some parts of a shared module.

Do you remember how to debug a single process in BW5? This was very simple, right? You were able to simply execute a single process with a given input and check its behavior quite quickly. Forget it with BW6.

Because of the OSGI engine, I assume, you will have to start your whole application (so waiting several dozens of seconds) before to execute a simple test on a single process. And even this part is far to be reliable. In my Studio, I am not able to do it every time. Sometimes when I am in debug mode, the pipeline containing the runtime variables is empty for whatever reasons. If you come from BW5, you will most likely hate the way to debug an application in BW6 Studio. Just like me.

As I said we have also to deal with complex schemas. You could obviously argue that the notion of complexity does not really exist for a schema. A schema is either compliant or not compliant with a standard. But if you are using abstract elements, multiple imports etc., believe me, there are complex for Studio. We faced so many problems in dealing with those schemas. I know that things were not perfect in BW5 but in BW6 this is a complete mess. Studio has many limitations and bugs. I feel like we spent more time finding Studio workarounds than actually developing core functions.

A new feature of BW6 is that each time you need to create a subprocess (for the non-TIBCO experts, a reusable piece of logic), it has to be based on a WSDL. Yes, a WSDL. Just ask a webMethods developer how long it takes to create a reusable flow service and to design its contract. Most likely few seconds. My mistake I thought BusinessWorks was supposed to be a development accelerator.
This was enhanced, though, with a recent release (direct subprocess) but now you still have to create an XSD. And it is not possible anymore to directly create elements in your process input as it was possible in BW5.

Do not expect to have a great CI support. There is a plugin made by TIBCO developers for Maven integration but there are so many limitations that you will most likely have to either fork it or create another one from scratch (I have seen both choices).

Runtime performance is another major problem. In a nutshell, BW6 performance is a disaster.

I ran simple performance tests to compare BW6 and Vert.x on exposing a simple REST service with a simple transformation. With Vert.x the average latency is less than one millisecond. With BW6 the average latency is 10 times longer. With 100 concurrent users, it is 27 times.

I tried to collaborate and to share my tests with TIBCO on the TIBCO ideas portal: https://ideas.tibco.com/ideas/AMBW-I-6.

Meanwhile, with the rise of reactive implementations, TIBCO should in my humble opinion tackle this. I also tried to share my thoughts about this topic on the TIBCO ideas portal: https://ideas.tibco.com/ideas/AMBW-I-5.

I always mention “I tried to share” because I never got any feedback from TIBCO since I published my first idea about 10 months ago. This is also very disappointing.

Conclusion

I could have mentioned many other problems and limitations (memory consumption, BW5 migration, TEA stability, palettes stability, SOAP limitations, Swagger limitations etc.) but I wanted this article to be concise, not a list of every problem I faced.

Clearly, though, BusinessWorks 6 is a disappointment for me, especially in regards to how great BW5 was and of my expectations for this new version.

This may seem like a paradox somehow but I do believe in the TIBCO company though. They already built great solutions in the past and I simply cannot believe they would not be able to achieve the same level of cleverness with BW6. But clearly, this will take time.

And until that time, in my opinion you should avoid TIBCO BusinessWorks 6.

If you do not share my point of view, feel free to open the discussion 😉

Tested BW version: 6.2, 6.3 and 6.4.x (x < 2)

  • Amitabh Singh

    Hello Sir,

    I saw your post for Tibco 6 Code review tool. Currently I am working on Tibco 6.4 and we need to implement a Code review Tool. I need your guidance for the same. Please help me in contacting you.

    Thanks,
    Amitabh