TIBCO BusinessWorks 6 Startup

I have probably included this within other BW6 discussions but it is important enough to stand alone as a separate article.

The TIBCO BusinessWorks 6 runtime environment is OSGi based. Applications run as OSGi bundles. This has the following benefits:

  • No classNotFoundException issues. If the required/imported packages are not available then the bundle will not resolve, thus the application will not start. This is a fail fast mechanism.
  • Promotes modular development. Developers can expose only those parts of the application that may be shared with other developers.
  • Run multiple versions of a single jar file in the same JVM without any errors.

When an application starts up, it sends asynchronous messages to all the OSGi bundles it depends on, such as resources bundle and palettes bundle. If one of the OSGi bundle fails to respond, the application displays an impaired state. The JVM (Appnode) continues running when an application is impaired. Eventually, when all OSGi bundles respond, the application switches to a started state. It is quite common to see applications in impaired state as they are starting up.

The TIBCO BusinessWorks engine itself is an OSGi bundle. An application verifies that the engine is available as it starts up. The engine then verifies that the application and all its dependencies (wiring) are available. All shared resources are evaluated and started up next.

Once the application dependencies are resolved and the shared resources are started, the application itself can be started. You will see the application starting up with impaired state, and after all dependencies are resolved, the application moves to a started state.

If an application does not startup, the TIBCO BusinessWorks engine does not terminate. The other OSGi bundles continue to run as well. This is very beneficial, since it allows you to now use OSGi commands to find out why your application did not start up.

A TIBCO BusinessWorks application contains one application module, which in turn consists of one or more processes that define the business logic, and zero or more shared modules. A process that is responsible for initiating the business logic at run-time is used to implement a component in an application module. Generally, each process in the application module becomes a separate component within the application module.

Applications can also contain OSGi bundles that do not contain application artifacts. For example, you can create an application that contains a Java OSGi bundle, which is also referred to as a Java module.

In terms of OSGi bundles, the usual alignment is that the application is a bundle, the application module is a bundle, and each shared module is a bundle.

If any of the process components within the application module are unresolved then the entire application module becomes unresolved and does not start. If the application module doesn’t start then none of the processes/services in the application can be started/executed.

It must be noted that not all run-time, service reference, or shared resource errors are detectable when the application is built or loaded and started. There are errors that are detectable only at process run-time.